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INTRODUCTION 


This  report  describes  a prototype  application  of  an  American 
National  Standards  Institute/Federal  Information  Processing 
Standard  to  manage  information  about  spatial  data.  The  impetus 
for  this  effort  emerged  from  the  Information  Technology  Standards 
Workshop,  March  1990,  sponsored  by  the  Geographic  Information 
Systems  (GIS)  Standards  Laboratory  at  the  National  Institute  of 
Standards  and  Technology  (NIST) . Research  and  development  of  the 
prototype  was  conducted  at  the  NIST  and  the  Institute  for  Land 
Information  Management,  University  of  Toronto,  an  academic 
participant  of  the  NIST  GIS  Standards  Laboratory. 

The  Information  Resource  Dictionary  System  (IRDS)  is  a software 
standard  for  managing  information  on  data  (metadata) . An  IRDS 
defines  data  entities,  identifies  their  locations  and  formats, 
establishes  and  describes  the  relationships  between  data  entities. 
The  IRDS  also  provides  an  extendable  structure  for  accommodating 
new  requirements,  as  well  as  an  interface  supporting  the  querying 
and  updating  of  the  dictionary  contents.  In  general,  the  IRDS 
ensures  the  data  security,  maintenance,  and  integrity  of  the 
database  it  is  supporting. 

Spatial  data  refer  to  locational  descriptions  of  geographic 
entities  and/or  their  associated  attributes.  Locational 
descriptions  are  expressed  by  names,  geographic  codes,  or  by  a 
coordinate  reference  system,  e.g.  latitude/ longitude . Issues 
pertaining  to  spatial  data  are  not  limited  to  data  capture, 
conversion,  format,  and  exchange.  The  management  of  spatial  data 
is  also  a crucial  concern,  a very  rapid  growth  in  GIS  has  greatly 
highlighted  this  issue  * 

GIS  are  computer  systems  for  capturing,  manipulating,  displaying, 
and  most  importantly,  analyzing  spatial  data.  Typically,  GIS  rely 
on  a database  management  system  (DBMS) . The  IRDS,  in  support  of 
the  DBMS,  facilitates  the  integration  of  spatial  data  on  a GIS,  the 
sharing  of  GIS  data  and  applications  between  GIS,  and  the 
integration  of  a GIS  with  its  own  corporate  computing  environment. 
GIS  are  most  effective  when  able  to  integrate  spatial  data  from 
various  sources.  GIS  applications  and  spatial  data  extend  over  a 
broad  range  of  disciplines,  consequently  GIS  users  must  be  able  to 
access  and  query  metadata  on  a variety  of  spatial  databases  on 
dissimilar  computer  systems. 

The  importance  of  the  IRDS  to  the  GIS  world  is  in  providing  data 
administration  and  management  functionality.  The  IRDS  is  scalable 
from  a data  dictionary  of  a single  database,  to  a data  directory 
of  many  data  dictionaries  within  an  organization  such  as  a federal 
agency,  to  a master  data  catalog  of  many  data  directories  within 
the  federal  government.  Potentially,  the  IRDS  has  a significant 
role  to  play  in  realizing  the  National  Spatial  Database 
Infrastructure  of  federal  agency  databases.  This  effort  is 
currently  envisioned  by  the  Federal  Geographic  Data  Committee 
(FGDC) , consisting  of  more  than  60  federal  agencies. 
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Because  much  of  the  social,  economic,  and  demographic  data  derived 
from  federal  sources  are  spatially  referenced,  GIS  can  use  the  IRDS 
to  access,  understand,  and  use  such  data  more  readily,  thereby 
providing  new  data  sources  for  GIS.  To  a large  degree,  the  IRDS 
assists  in  evaluating  spatial  data  for  its  fitness  for  use. 

The  need  for  data  administration  and  management  in  GIS  technology 
is  becoming  more  evident  as  increasing  data  sharing  occurs  in  earth 
science,  corporate  management,  and  consumer  applications  of  GIS 
technology.  Software  standards,  such  as  the  IRDS,  will  rapidly 
assume  greater  and  more  prominent  roles  in  data  sharing.  This 
report,  presented  in  the  Integration  and  GIS  technical  session  at 
the  1991  Urban  Regional  Information  Systems  Association's  (URISA) 
annual  meeting,  attained  immediate  acceptance  as  a milestone  in  GIS 
integration.  Certainly,  this  pioneering  study  demonstrates  not 
only  the  feasibility,  but  also,  the  great  value  of  applying 
information  technology  standards  to  administer  and  manage 
geographic  information  resources. 


Henry  Tom 

NIST  GIS  Standards  Laboratory 
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ABSTRACT 


The  management  of  geographic  information  resources  (GIRs)  continues  to  be  plagued  by 
problems  of  monitoring,  locating  and  controlling  the  array  of  geographic  information  in 
complex  organizations.  Software  tools  to  support  these  functions  are  fundamental  to  any 
effort  to  maintain  the  integrity  of  geographic  information  as  it  changes.  In  addition,  such 
tools  are  desirable  when  formalizing,  then  managing  the  integration  of  geographic 
information  resources  within  an  organization.  One  of  the  major  approaches  to  this  problem 
in  the  area  of  database  systems  has  been  development  of  the  information  resource  dictionary' 
(IRD)  which  contains  meta-data.  An  Information  Resource  Dictionary  System  (IRDS)  is 
a database  of  meta-data  along  with  software  and  procedures  for  the  creation  and 
maintenance  of  the  IRD.  In  1989  the  American  National  Standards  Institute  (ANSI) 
X3. 138-1988  IRDS  (ANSI-IRDS)  was  adopted  as  Federal  Information  Processing  Standard 
156  by  the  United  States  Government.  ANSI-IRDS  is  intended  to  support  the  definition, 
management  and  control  of  mete-data.  This  study  presents  the  first  known  attempt  to 
actually  apply  ASSI-1RDS  in  the  geographic  information  management  domain. 

The  application  of  IRDS  to  technical  data  management  at  an  airport  is  used  to  study  the 
capabilities  of  ERDS  in  a geographic  data  management  context.  Using  the  Entity- 
Relationship-Attribute  (E-R-A)  model  upon  which  ANSI-IRDS  is  based,  a geographic  data 
model  (GDM)  of  the  GIRs  involved  in  the  facility  alteration  permit  process  was  developed. 
Conversion  of  the  airport  GDM  to  the  ANSI-IRDS  was  carried  out  at  the  National  Institute 
of  Standards  and  Technology.  Development  of  the  GDM  and  its  conversion  to  an  E-R-A 
model  is  discussed.  Observations  from  this  modelling  effort  will  be  presented.  Special 
consideration  is  given  to  the  demands  that  modelling  GIRs  made  upon  development  of  a 
Geographic-IRDS. 
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1.  INTRODUCTION 

This  report  describes  a cooperative  project  undertaken  as  part  of  a Research  Participation 
Agreement  with  the  Geographic  Information  Systems  Standards  Laboratory,  National 
Institute  of  Standards  and  Technology,  Gaithersburg  and  the  Institute  for  Land  Information 
Management,  University  of  Toronto  for  research  and  development  in  the  area  ofIRDSs  and 
Geographic  Information  Systems  (GISs). 

IRDSs  represent  a new  software  tool  which  has  the  potential  to  control,  describe  and  cross 
reference  meta-data  within  a GIS.  Relationships  between  geographic  features  may  be 
constrained  and  integrity  rules  maintained,  leading  to  efficiency  in  the  storage  and 
processing  of  geographic  data  in  GISs. 

1.1  Purpose 

The  main  purpose  of  this  project  is  to  gain  competency  in  the  application  ofIRDSs  to  a GIS 
problem.  This  problem  area  is  specific  to  airports.  Our  goal  is  to  build  a prototype 
Geographic  Information  Resource  Dictionary  System  (GIRDS)  in  which  it  is  possible  to 
model: 

• the  maintenance  of  geographic  data  at  airports  in  Canada; 

• geographic  data  located  on  the  Airside  and  Groundside  of  an  airport; 

• geographic  data  common  to  both  the  Airside  and  Groundside  of  an  airport; 

and  control  and  constrain  meta-data  associated  with  airport  geographic  features  and  the 
maintenance  of  these  features. 
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1.2  Scope 

The  project  has  seven  main  parts: 

• Reviewing  IRDS  applications,  conceptual  modelling  tools  and  the  IRDS 
architecture. 

• Identifying  the  role  of  IRDS  in  airport  GIS. 

• Reviewing  the  data  stored  by  Canadian  airports  and  the  Facility  Alteration 

Permit  (FAP)  process  currently  used  for  geographic  data  maintenance. 

• Building  Entity-Relationship  models  for  airport  geographic  data  and  the  FAP 
process. 

• Converting  this  integrated  GDM  to  an  IRDS  E-R-A  model. 

• Prototyping  the  GIRDS  by  building  IRD  Schema  definition  tables  and  IRD 

definition  tables. 

• Demonstrating  and  documenting  the  results. 

1.3  Disclaimers 

This  project  is  a research  venture  in  the  area  of  IRDS  and  its  application  in  GIS.  It  is  to 
a large  extent  specific  to  geographic  data  management  at  an  airport.  Hence,  it  is  driven  by 
the  author’s  view  of  geographic  features  on  a specific  airport.  Therefore,  this  study  is  not 
intended  to  suggest  a universally  acceptable  model. 

Certain  commercial  products  are  identified  in  this  report  in  order  to  adequately  specify  the 
procedures  being  described.  In  no  case  does  such  identification  imply  recommendation  or 
endorsement  by  the  National  Institute  of  Standards  and  Technology  or  the  Institute  for  Land 
Information  Management,  nor  does  it  imply  that  the  product  identified  is  necessarily  the 
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best  for  the  purpose. 
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2. 


DESCRIPTION  OF  THE  APPLICATION 


Airport  managers  spend  millions  of  dollars  each  year  in  an  attempt  to  manage  their 
infrastructure  by  way  of  Capital  Improvement  Programs  and  Facility  Alteration  Permits 
(FAPs)  (Robinson  and  Sani,  1990).  Data  obtained  through  these  processes  are  transmitted 
to  Technical  Data  Centre  (TDC)  managers  for  storage  and  dissemination,  yet  airports 
remain  data  rich  and  information  poor. 

In  Canada,  Federal  government  policy  states  that  commercialization  and  self-sufficiency  of 
airports  are  national  objectives.  To  efficiently  carry  out  their  responsibilities  and  realize 
these  objectives,  airport  managers  must  have  access  to  up-to-date  information. 

Recognizing  this,  Transport  Canada,  Headquarters,  contracted  with  the  Institute  for  Land 
Information  Management  (ILIM),  University  of  Toronto,  to  undertake  a feasibility  study  for 
implementing  GISs  at  airports  (Robinson  and  Sani,  1990).  This  study,  while  concluding  that 
GIS  is  feasible,  noted  that  airports  currently  lack  the  ability  to  handle  and  analyze 
geographic  relationships.  It  also  noted  that  it  is  desirable  to  integrate  information  across 
multiple  geographic  data  sets  so  that  a consistent  corporate  set  of  geographic  information 
resources  exist  at  the  TDCs  which  would  facilitate  on-going  geographic  data  management 
at  Canadian  airports. 

The  concept  of  an  airport  GIS  (ACTS)  is  relatively  new.  To  date,  this  concept  has  not  been 
extensively  employed  at  North  American  airports  (Robinson  and  Sani,  1990).  However, 
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many  airports  are  now  considering  this  technology  in  an  attempt  to  manage  what  may  be 
described  as  dynamic,  complex  environments  which  must  address  security,  emergency, 
planning,  engineering  and  environmental  concerns.  In  addition,  maintenance,  commercial 
leasing  and  expansion  activities  must  be  coordinated  and  integrated. 

A GIS  allows  managers  to  input,  store,  analyze,  output  and  disseminate  information. 
However,  while  most  systems  ensure  topological  consistency  of  data,  a GIS  system  does  not 
have  software  tools  w'hich  design,  monitor,  locate,  protect  or  control  the  data  stored  - a 
necessary  requirement  for  data  integrity.  Collectively,  these  software  tools  are  commonly 
referred  to  as  an  IRDS  and  are  used  for  information  resource  management  applications. 

There  have  been  no  GIS  related  IRDS  implementations  reported  to  date.  Some  related 
efforts  include  the: 

• modelling  of  the  Land-Related  Information  (LRI)  Dictionary/Directory 
System  in  Alberta  to  manage  data  effectively  in  the  LRI  System  Network 
(Alberta  Land-Related  Information  Systems  Group,  1989); 

• integration  of  a Dictionary /Directory  (D/D)  System  in  a centralized  database 
environment  and  the  necessary  software  interfaces  to  the  centralized  D/D  to 
function  as  a distributed  database  management  system  (DBMS),  (Allen  et  al, 
1982); 

• integration  of  a catalogue  in  the  Spatial  Data  Transfer  Standard  (SDTS)  to 
identify  the  location  of  modules  within  the  transfer  and  to  cross-reference  the 
relationships  between  modules,  spatial  domain,  maps,  map  layers  and  entities 
(Morrison,  1988). 

An  integration  of  technologies  - GIS  and  the  ANSI-1RDS  - is  proposed  for  this  study.  To 
achieve  this  integration,  as  a first  step,  Entity-Relationship  models  describing  airport 
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geographic  features  and  their  relationships  is  required.  Entity-Relationship  models  are  also 
required  of  the  airport  geographic  database  maintenance  process  currently  administered 
through  the  use  of  FAPs,  in  order  that  an  integrated  approach  to  geographic  data 
management  is  achieved.  This  comprehensive  airport  data  model  is  referred  to  as  the 
GDM. 


Conversion  of  the  airport  GDM  to  the  ANSI-IRDS  was  carried  out  at  the  United  States 
Department  of  Commerce,  National  Institute  of  Standards  and  Technology,  Gaithersburg, 
Maryland,  USA.  The  conversion  involved,  as  a first  step,  re-defining  the  E-R  data  model 
in  terms  of  the  IRDS  E-R-A  model  in  order  that  entity-types  and  relationship-types  are 
easily  identified.  Next,  an  empty  IRD  had  to  be  created  and  the  IRD  Schema  defined  prior 
to  compiling  the  ANSI-IRDS  commands.  Section  11  details  this  process. 
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3. 


INFORMATION  RESOURCE  DICTIONARY  SYSTEM  CONCEPTS 


Wertz  describes  a data  dictionary  system  as  a computerized  database  of  meta-data  (data 
about  data),  together  with  software  and  procedures  used  to  create  and  maintain  the 
dictionary  database  (Wertz,  1989). 


An  Information  Resource  Dictionary  (IRD)  or  data  dictionary,  is  a highly  structured  type 
of  database  which  can  be  used  to  design,  monitor,  locate,  protect  and  control  information 
resources  in  information  systems  (Law,  1988). 


Data  dictionaries  are  fundamentally  different  from  databases.  Databases  hold  the  data 
values  stored  for  data  items,  while  a data  dictionary  contains  information  about  data  items. 
Examples  of  information  about  a data  item  that  a data  dictionary  can  support  are: 

• category  of  the  data  item; 

• relationships  of  the  data  item  to  other  data  items; 

• when  and  by  whom  it  was  defined; 

• when  and  by  whom  it  was  modified; 

• total  number  of  modifications; 

• description  of  the  data  item  such  as  its  format; 

• databases  or  files  in  which  the  data  item  appears; 

• location  of  the  data  item  in  the  database  or  files; 

• set  or  range  of  valid  data  items  permitted  for  a data  item  in  the 
database  (Law,  1988). 

An  IRDS  is  a software  system  that  allows  IRD  applications  to  be  developed. 


7 


3.1  Need  for  an  IRDS 


Today,  many  organizations  have  large  volumes  of  data  stored  in  hard  copy  or  on  disk.  Data 
is  often  not  validated  and  may  be  incorrect  or  incomplete.  Organizations  employing 
geoprocessing  systems  may  suffer  from  both  operating  and  data  related  problems.  Operating 
problems  may  be  characterized  by  redundant  data,  redundant  processing,  complexity  and 
interdependence,  inflexibility  and  lack  of  adequate  documentation.  Data  related  problems 
are  characterized  by  inconsistent  data,  inconsistent  representations  and  codes,  inconsistent 
timing,  lack  of  understanding  among  systems,  lack  of  good  data  and  lack  of  organization. 
Many  of  these  operating  and  data  related  problems  are  difficult  to  quantify  (Wertz,  1989). 

Most  organizations  concerned  with  effective  information  management,  data  processing,  data 
conversion  and  communications  adopt  Information  Resource  Management  (1RM)  policies. 
These  policies  coordinate  the  development,  operation  and  maintenance  of  an  organization’s 
information  system.  An  IRDS  provides  many  functions  useful  for  data  administration,  as 
shown  in  Table  1,  by  providing  a medium  for  meta-data  description,  cross  references  and 
consistency  checking  (Law,  1988). 
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TABLE  1 - IRDS  applications 

APPLICATION 

DESCRIPTION 

Data  Element 
Standardization 

An  IRD  supports  the  standardization  of  data  element 
names,  definitions  and  relationships,  which  ensures  consistent 
data  elements  are  stored  in  the  database  and  that  files  can  be 
accessed  by  multiple  users  and  programs. 

Database 

Validation  (DV) 

DV  is  accomplished  by  building  data  integrity  rules  in  an 

IRD.  For  example,  a range  of  values  may  be  defined  for  a 
particular  entity-type  that  are  permissible  for  any  instance  of 
such  an  entity. 

Data  Resource 
Management  (DRM) 

DRM  may  be  performed  by  an  IRD  to  describe  the  use, 
location  and  mode  of  data  representation  of  on-line  geographic 
databases,  computer  graphic  images,  archived  data  on  disk  and 
database  reports. 

System  Resource 
Configuration 
Management  (SRCM) 

SRCM  involves  tracking  structures  and  changes  for  all 
resources  used  in  one  or  more  information  systems.  An 

IRD  can  be  used  as  both  a directory  to  locate  data  or  item 
sources,  and  as  a dictionary  to  describe  configuration  item 
information. 

Hardware 

Configuration 
Management  (HCM) 

HCM  describes  the  use,  location  and  structure  of 
computer  and  communications  hardware  used  to  support 
an  information  system.  An  IRD  can  be  designed  as  a hardware 
directory  to  list  and  locate  hardware  and  peripherals  required 
for  computer  and  communications  systems  maintenance, 
replacement  and  repair. 

Software 

Configuration 
Management  (SCM) 

SCM  describes  the  use,  location  and  structure  of 

reusable  software  items.  To  support  this  task,  an  IRD 

can  be  used  as  a Source  Code  Directory  that  lists  and  locates 

the  programs,  subroutines,  functions,  software  utilities  and 

languages  available  in  one  or  more  software  libraries  (Law, 

1988). 
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4. 


DATA  MODELLING  FOR  IRDS 


A data  model  is  a collection  of  conceptual  tools  for  describing  data,  relationships,  semantics 
and  constraints  (Korth  and  Silberschatz,  1986).  The  ANSI-IRDS  is  based  on  the  Entity- 
Relationship-Attribute  (E-R-A)  model  which  is  an  extension  to  the  Entity-Relationship  (E- 
R)  model. 

4.1  Entity-Relationship  Model 

The  E-R  model  views  the  world  as  consisting  of  entities  and  relationships.  The  model 
achieves  a high  degree  of  data  independence,  which  means  that  applications  are  immune 
to  changes  in  storage  structure  and  access  strategy  (Date,  1986).  It  is  based  on  set  theory 
and  relational  theory  w’hich  formulates  the  definition  of  a desired  relation  in  terms  of  those 
given  relations.  It  may  also  be  used  as  the  framework  from  which  the  Relational  and 
Network  models  are  derived  (Chen,  1976). 

4.1.1  Mapping  Constraints 

The  connectivity  of  a relationship  specifies  the  mapping  of  the  associated  entity  occurrences 
in  the  relationship.  Values  for  connectivity  are  either  "one" or  "many".  The  actual  number 
associated  with  the  term  many  is  called  the  cardinality  of  the  connectivity.  The  basic  types 
of  connectivity  are  one-to-one  (1: 1),  one-to-many  (1:N)  and  many-to-many  (N:N)  (Chen, 
1976).  Figures  1-4  illustrate  these  concepts.  Partial  relationships  between  entities  are 
defined  by  upper  and  lower  cardinalities. 
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Figure  1 - 4 - E-R  relationships 
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When  the  lower  bound  is  one  or  many,  it  is  a total  or  obligatory  relationship.  When  the 
lower  bound  is  zero,  it  is  a partial  relationship. 

4.2  The  Extended-Entity-Relationship  Model 

The  E-R  model,  although  modified  and  extended  by  others  to  provide  greater  semantics, 
remains  the  premier  model  in  conceptual  design  for  communicating  fundamental  data  and 
relationship  definitions  with  the  end  user  (Teorey  et  al,  1986).  Using  the  E-R  model  as  a 
conceptual  schema  representation,  however,  has  proved  difficult  because  of  limitations  of 
the  original  modelling  constructs.  For  example,  data  integrity  involving  null  attribute  values 
requires  defining  relationships  such  that  a null  set  on  either  side  of  the  relationship  is  either 
allowed  or  disallowed.  Also  certain  relationships  of  degree  higher  than  2 (binary)  may  be 
present  and  are  awkward  when  represented  in  binary  form.  The  Extended-Entity- 
Relationship  (E-E-R)  model  provides  alternate  representations  for  these  commonly  used 
concepts  and  is  compatible  with  the  simplicity  of  the  original  E-R  model  (Teorey  et  al, 
1986).  This  model  is  now  referred  to  as  the  Entity-Relationship-Attribute  (E-R-A)  model 
(Rosen  and  Law,  1990). 

4.2.1  Degree  of  Relationship 

The  degree  of  relationship  is  the  number  of  entities  associated  in  the  relationship.  An  n-ary 
relationship  is  of  degree  n.  Unary,  binary  and  femary  relationships  are  special  cases  where 
the  degree  is  1,  2 and  3 respectively. 
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4.2.2  Connectivity  of  a Relationship 

Constructs  for  connectivity  in  the  E-R  model  are  1:1  (unary  and  binary  relationship),  1:N 
(unary  and  binary  relationships)  and  N:N  (unary  and  binary  relationships).  The  E-R-A 
model  supports  n-ary  relationships  for  N >2. 

4.2.3  Diagramming  Techniques 

The  E-R  and  E-R-A  diagrams  are  graphic  portrayals  of  E-R  algebra.  Figure  5 illustrates 
the  components  of  E-R  and  E-R-A  diagrams. 
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Figure  5 - E-R  and  E-R-A  diagramming  techniques 


5. 


THE  AMERICAN  NATIONAL  STANDARDS  LNSTITLTE  INFORMATION 


RESOURCE  DICTIONARY  SYSTEM 


An  IRDS  is  a set  of  software  specifications  for  a standard  data  dictionary  system.  The 
ANSI-IRDS  Standard  establishes  the  requirements  for  a software  tool,  which  can  be  used 
to  control,  describe  and  facilitate  the  use  of  an  installation’s  information  resources.  The 
description  of  the  information  resource  is  a specific  type  of  information  referred  to  as  meta- 
data. The  ANSI-IRDS  is  intended  to  support  the  definition,  management,  and  control  of 
meta-data.  It  was  approved  by  the  American  National  Standards  Institute,  Inc.  in  1988,  and 
was  published  as  ANSI  Standard  X3. 138-1988.  On  April  5,  1989,  it  was  adopted  as  Federal 
Information  Processing  Standard  156  (FIPS  156). 

5.1  Purpose  of  the  ANSI-IRDS  Standard 

The  purpose  of  the  FIPS  ANSI-IRDS  Standard  is  to  provide  the  United  States  Federal 
government  with  a data  dictionary  to  support  all  phases  of  the  system  life-  cycle.  The  ANSI- 
IRDS  Standard  is  estimated  to  save  the  U.S.  Federal  government  over  $120  million  (in 
constant  1983  dollars)  in  benefits  by  the  early  1990's  (Chipman  and  Fiorello,  1983). 
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5.2  Organization  of  the  ANSI-IRDS  Standard 

ANSI  X3. 138-1988  is  organized  into  7 modules:  1)  Core  Standard,  2)  Basic  Functional 
Schema,  3)  IRDS  Security,  4)  Extensible  Life  Cycle  Phase  Facility,  5)  Procedure  Facility, 
6)  Application  Program  Interface  and  7)  Entity  Lists.  All  the  specifications  of  ANSI  X3. 138- 
1988  apply  to  this  standard  with  one  exception:  In  the  chapter  "Requirements  for  a 
Conformant  Implementation"  of  ANSI  X3.138-1988.  it  is  stated  that  each  of  Modules  2 
through  7 are  optional.  All  implementations  of  FIPS  156,  however,  must  include  the  Basic 
Functional  Schema. 

5.3  The  Architecture  of  the  ANSI-IRDS 

As  shown  in  Figure  6 . the  ANSI-IRDS  Database  can  be  viewed  as  a four-level  architecture 
in  which  information  specified  at  one-level  describes,  and  potentially  controls,  information 
stored  at  the  next  lower  level.  Thus,  one-level  defines  the  types  of  "objects"  which  can  be 
described  at  the  next  lower  level,  and  that  level  contains  the  "instances"  of  those  types. 
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Figure  6 - The  four  level  architecture  of  the  ANSI-IRDS 
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The  top  level  of  the  four-level  architecture  is  defined  by  the  ANSI-IRDS  implementor.  This 
level  contains  the  types  of  objects  and  relationships  which  can  exist  and  can  be  defined  at 
the  IRD  Schema  level.  These  types  are  referred  to  as  meta-entity-types,  meta-relationship- 
types  and  meta-attribute-types. 

The  second  level  is  referred  to  as  the  Information  Resource  Dictionary  (IRD)  Schema.  This 
level  defines  the  types  to  be  included  in  the  IRD.  It  also  defines  various  control 
mechanisms,  including  naming  rules,  defaults  and  validation  information  for  the  IRD 
contents. 

The  third  level,  the  IRD,  describes  the  environment  being  modelled  by  the  objects  in  the 
environment  and  the  association  among  these  objects;  the  object  descriptions  are  called 
entities,  and  the  association  descriptions  are  called  relationships.  This  level  also  describes 
the  properties  of  the  objects  and  their  associations,  i.e.  their  attributes. 

The  fourth  level,  not  described  in  the  standard,  is  the  information  resources  environment. 
It  is  the  "real  world  information  resources’  the  descriptions  of  which  exist  in  the  IRD. 
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5.4  The  ANSI-IRDS  Data  Mode! 


The  ANSI-IRDS  uses  an  E-R-A  data  modelling  approach  to  describe  the  contents  of  both 
the  IRD  and  the  IRD  Schema.  The  ANSI-IRDS  data  model  is  distinguished  by  the 
following  characteristics  (Table  2): 

TABLE 2 - Characteristics  of  the  ANSI-IRDS  data  model 


Characteristics 

Explanation 

Binary  E-R-A 

Any  relationship  may  connect  at  most 
two  entities. 

Relationships  are 
directed  associations 

Relationship  of  entity  A -*  B is  not 
the  same  as  B ->  A. 

Both  entities  and 
Relationships  may 
have  attributes 

The  access-name  uniquely  defines  entities  and 
relationships. 

Attribute  grouping 

One  level  of  attribute  grouping  permitted. 

Strongly  typed 

Entities,  relationships  and  attributes  may  have  one  type  only. 
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The  typing  of  entities,  relationships  and  attributes  provides  the  following  (American 
National  Standard  Institute,  Inc.  198S): 

For  an  entity,  the  entity  type  defines  how  the  entity  can  be  named. 

The  relationship-type  defines: 

(i)  whether  or  not  a given  pair  of  entities  can  be  associated. 

(ii)  how  the  relationship  can  be  specified. 

(iii)  whether  or  not  there  can  exist  more  than  one  relationship  of  a 
given  type  associating  the  same  two  entities. 

For  an  attribute,  the  attribute  type  defines  how  the  attribute  is 
identified  and  what  maintenance  operations  can  be  performed  against 
it. 

For  an  attribute-group,  the  attribute-group-type  defines: 

(i)  which  types  of  attributes  can  be  grouped. 

(ii)  the  ordering  of  attributes  within  the  group. 

(iii)  which  attributes  can  be  specified  whenever  there  are  multiple 
entries  of  the  attribute-group-type  within  a given  entity  or 
relationship. 

Any  given  entity,  relationship,  relationship-class,  attribute,  or  attribute  group  is  called  a 
descriptor.  In  order  to  distinguish  between  those  descriptors  within  the  IRD  and  the  IRD 
Schema,  the  following  terminology  is  used: 
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The  term  IRD  descriptor  refers  to  any  descriptor  which  resides  in  the  IRD.  The  term  IRD 
Schema  descriptor  refers  to  any  descriptor  which  resides  in  the  IRD  Schema.  The  terms 
entity,  relationship,  relationship-class,  attribute  and  attribute-group  are  IRD  descriptors. 

In  order  to  distinguish  IRD  descriptors  from  IRD  Schema  descriptors,  the  prefix  meta  is 
used  in  reference  to  the  IRD  Schema.  Thus  the  terms  meta-entity,  meta-relationship,  meta- 
relationship-class,  meta-attribute  and  meta-attribute-group  are  IRD  Schema  descriptors. 

Therefore,  every  entity-type,  relationship-type,  attribute-type,  and  attribute-group-type 
represented  in  the  IRD  must  also  be  represented  in  the  IRD  Schema  by  a meta-entity-type, 
meta-relationship-type,  meta-attribute-type  and  meta-attribute-group-type.  Significant 
differences  between  the  IRD  Schema  and  the  IRD  are  shown  in  Table  3. 


TABLE  3 - Differences:  IRD  Schema  and  IRD 


ERD  Schema  IRD 

Types  of  meta-en tides,  meta-relationships  Entity-types,  relationship- types,  and 
and  meta-attributes  are  predetermined  by  attribute-types  are  determined  by  user 
ANSI-IRDS  Standard. 


Meta-relationship-type  is  completely 
defined  by  a pair  of  entity-types 

Meta-relationship-types  constrained 
to  (0,N:0, 1),  (0,N:2)  or  (0,N:0,N) 


Multiple  relationship-types  involving  the 
same  pair  of  entity-types 

All  relationship-types  are  unconstrained 
(0,N:0,N) 
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The  ANSTIRDS  use  of  the  E-R-A  model  is  defined  in  terms  of  data  typing.  The  structure 
of  each  IRDS  application,  known  as  an  IRD,  is  defined  in  terms  of  entity-types,  relationship- 
types,  attribute-types  and  attribute-group-types.  Each  entity  in  the  IRD  therefore  has  a 
unique  type  referred  to  as  the  entity-type  of  the  entity.  Similarly,  each  relationship  in  the 
IRD  has  a unique  type  called  the  relationship-type.  For  a given  entity-type  or  relationship- 
type,  there  is  a defined  set  of  attribute-types  and  attribute-group-types  associated  with  the 
entity-type  or  relationship-type,  and  every  attribute  and  attribute-group  of  an  entity  or 
relationship  of  the  particular  type  must  correspond  to  one  of  these  attribute-types  or 
attribute-group-types.  The  definition  of  these  types  in  an  IRD  Schema  provide  the 
framework  on  which  the  data  contents  of  the  dictionary  will  be  based. 

5.5  Definition  of  the  Standard  ANSI-IRDS 

The  ANSI-IRDS  is  composed  of  seven  modules  (American  National  Standard  Institute,  Inc., 
1988).  The  Core  module  consists  of  the  IRD  Schema  Description,  the  Minimal  IRD 
Schema,  either  the  Command  Language  Interface  or  Panel  Interface  or  both  and  the  IRD. 
The  ANSI-IRDS  supports  commands  for  IRD  Schema  maintenance  by  allowing  the  user  to 
add,  modify,  and  delete  entities  and  relationships  in  the  IRD.  It  also  allows  output  of  the 
IRD,  and  IRD-IRD  interface  commands. 
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5.5.1  The  IRD  Schema 


The  IRD  Schema  describes  the  structure  of  the  IRD.  For  e\ery  entity,  relationship, 
attribute,  and  attribute  group  that  can  exist  in  the  IRD,  the  IRD  Schema  will  contain  the 
corresponding  entity-type,  relationship-type,  attribute-type  and  attribute-group-type.  The 
standard  specifies  specific  entity-types,  relationship-types  and  attribute-group-types.  These 
types  are  organized  into  the  Minimal  Schema  of  Module  1 and  the  Basic  Functional  Schema 
of  Module  2. 

The  IRD  Schema  is  important  because  the  ANSI-IRDS  specifications  include  facilities  to 
enable  an  organization  to  extend  the  Minimal  Schema  (Module  1)  or  Basic  Functional 
Schema  (Module  2).  This  means  that  an  organization  can  add  additional  entity-types, 
relationship-types,  attribute-types  and  attribute-group-types  to  satisfy  its  needs. 

5.5.2  The  Minimal  Schema 

Software  conforming  to  the  ANSI-IRDS  specifications  must  include  the  Minimal  Schema, 
a collection  of  entity-types,  relationship-types,  attribute-types,  and  other  IRD  descriptors 
necessary  to  establish  control  over  the  IRD  Schema  and  the  IRD.  For  example,  the 
Minimal  Schema  includes  the  entity-types  IRD-USER,  IRD-VIEW  and  IRD-SCHEMA- 
VIEW,  the  relationship  types  IRDS-USER-HAS-IRD-VIEW  and  IRDS-USER-HAS-IRD- 
SCHEMA-VIEW,  and  the  attribute-type  DEFAULT-VIEW,  which  are  used  to  control 
access  to  the  contents  of  the  IRD  and  the  IRD  Schema.  The  attribute-types  ADDED-BY, 
LAST-MODIFIED-BY,  and  NUMBER-OF-TIMES-MODIFIED,  and  the  attribute-group 
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types.  DATE-TIME-ADDED  and  DATE-TIME-LAST-MODIFIED  automatically  document 
information  concerning  changes  to  the  IRD  and  its  Schema  (Goldnne  and  Konig.  1988). 

The  relationship-types  IRDS-USER-HAS-IRD-VIEW  and  IRDS-USER-HAS-IRD- 
SCHEMA-VIEW  are  associated  with  the  attribute-type  DEFAULT-VIEW,  which  can  have, 
at  most,  a single  attribute  per  relationship.  The  Minimal  Schema  does  not  contain  any 
attribute-group-types  associated  with  any  relationship-type. 

Associated  with  the  Minimal  Schema  are  the  following  meta-entities  - Attribute-Type- 
Validation-Data,  Attribute-Type-Validation-Procedure,  IRD-Partition,  IRDS-Defaults,  IRDS- 
Limits  and  IRDS-Reserved-Names.  The  Type-Validation  meta-entities  validate  attributes 
prior  to  entry  in  the  IRD.  The  Defaults  meta-entity  is  used  to  establish  organizational 
defaults  for  assigned  name-lengths,  for  the  number  of  occurrences  of  entities  of  a particular 
type,  and  for  attribute-lengths.  The  Limits  meta-entity  is  used  to  establish  organizationally 
defined  limits  and  initial  values  for  name-lengths,  dates  and  times,  and  values  of  other  meta- 
attribute-types.  The  Reserved- Names  meta-entity  specifies  the  assigned-access-names  of 
those  entities  and  meta-entities  that  are  required  by  the  ANSI-IRDS  Specifications. 

The  Minimal  Schema  contains  one  NAMES  meta-entity  called  NAMING-RULES.  It  is 
intended  for  user  documentation  and  contains  a description  of  the  rules  for  naming  entities. 
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5.5.3  Command  Language  and  Panel  Interface 

An  ANSI-IRDS  implementation  may  include  either  a Command  Language  or  Panel 
interface.  Currently,  only  a Command  Language  Interface  has  been  implemented  on  the 
prototype  developed  at  National  Institute  of  Standards  and  Technology  (NIST), 
Gaithersburg  (Kirkendall,  1990).  It  supports  user  interaction  with  the  ANSI-IRDS  in  both 
batch  and  interactive  modes.  The  Panel  Interface  provides  the  ANSI-IRDS  user  with  a set 
of  logical  screens  or  panels.  These  panels  are  further  structured  into  panel  trees  or  panel 
areas. 


5.5.4  The  IRD 

The  ANSI-IRDS  provides  an  IRD-IRD  interface  to:  (i)  allow  movement  of  data  from  one 
standard  ANSI-IRDS  implementation  to  another;  (ii)  create  an  empty  (IRD);  (iii)  to  check 
compatibilities  of  Schemas  prior  to  data  transfer;  and  (iv)  import  a previously  exported  IRD 
Schema  and  an  IRD  subset  into  the  target  environment. 

The  Core  ANSI-IRDS  contains  four  facilities  for  creating  and  maintaining  the  IRD  and 
reporting  on  its  contents.  There  are  facilities  for  (i)  Versioning  - the  ability  to  track  each 
revision  as  a distinct  entity  in  the  IRD,  (ii)  Life  Cycle  Phases  - the  ability  to  document  the 
life  cycle  of  an  entity,  (iii)  Quality  Indicators  for  entities  and  (iv)  IRD-Views  for  supporting 
project-oriented  activities. 
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6. 


INFORMATION  RESOURCE  DICTIONARY  SYSTEM 


AND  GEOGRAPHIC  INFORMATION  SYSTEM 


A GIS  is  a set  of  tools  for  collecting,  storing,  retrieving,  transforming  and  displaying  spatial 
data  for  a particular  set  of  purposes  (Burrough,  1986).  Geographical  data  describe  objects 
from  the  real  world  in  terms  of: 

• their  position  with  respect  to  a known  coordinate  system; 

• their  attributes  that  are  related  to  position;  and 

• their  geographic  relationships. 

An  AGIS  is  used  to  integrate,  manage  and  analyze  airport  site  data.  As  with  any  GIS,  it 
consists  of  three  components  - computer  hardware,  application  software  and  a proper 
organizational  context  (Burrough,  1986). 


Some  applications  of  AGIS  include: 

• integrating  geographically-referenced  information  and  description  of  available 
areas  for  leasing  at  any  given  time  based  on  proposed  airside  and  groundside 
expansions. 

• integrating  geotechnical,  geographical,  environmental  and  capital  project 
information  so  that  an  automated,  or  semi-automated  screening  procedure  can 
exploit  project  drawings  and  surrounding  as-built  drawings.  This  integrated 
information  will  support  timely  and  complete  environmental  audits. 

• managing  changes  in  the  physical  boundaries  of  the  airport  and  relating  those 
changes  to  responsibilities  for  land/or  buildings  for  input  to  Airport 
Maintenance  Management  Systems. 
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• enhancing  the  consistency  and  conformance  checking  process  in  Planning 
Departments  by  ensuring  that  changes  which  occur  through  the  FAP  process 
is  in  accordance  with  Area  Master  Planning  documents. 

• relating  ground  transportation  infrastructure  such  as  roadways,  parking  lots 
and  curbs  to  survey  data  to  assist  in  the  design  of  ground  transportation 
facilities. 

• routing  of,  and  determining  response  times  for  emergency  vehicles. 

• locating  isolation  and  staging  areas  for  security  purposes  (Robinson  and  Sani, 
1990). 


6.1  Role  of  the  ANSI-IRDS  in  Airport  GIS 

Airports  are  dynamic  environments  that  serve  millions  of  travellers  each  year.  Information 
collected  and  maintained  by  each  site  is  extensive,  both  in  range  and  volume.  As  an 
example,  databases  at  Toronto  - Lester  B.  Pearson  International  Airport  (LBPIA)  concern 
inventories  on  site,  permitting  facilities,  enforcement  actions  and  maintenance  activities. 
The  inventories  database  is  estimated  at  one  to  two  hundred  megabytes  (MB). 

Airport  databases  have  not  been  managed  as  a corporate  resource  (Robinson  and  Sani, 
1990).  At  all  large  airports,  databases  have  been  created  by  allowing  separate  departments 
and  systems  to  collect  and  handle  information  independently.  Unguided  development  of 
databases  has  led  to  inconsistent  data  capture,  inconsistent  storage  of  data  elements  and 


27 


inadequate  definition  of  non-graphic  data.  It  has  also  contributed  to  the  fact  that  data 
shared  across  organizational  boundaries  does  not  always  meet  user  requirements  for 
consistency.  Therefore  managers  often  obtain  inconsistent  views  of  various  operations  in 
their  organization.  As  a result,  little  confidence  is  placed  in  the  data  by  decision-makers 
(Robinson  and  Sani,  1990). 

6.2  The  Role  of  an  ANSI-IRDS/GIS  in  Airport  Geographic  Data  Management 

GISs  collect,  store,  manage  and  manipulate  data,  and  provide  a means  for  importing  and 
exporting  information.  Their  main  function  in  an  organization  is  to  produce  information 
from  data.  This  necessitates  data  validation  and  consistency  checking.  GISs  can  generally 
accomplish  these  tasks  in  a narrow  application  domain,  but  not  across  an  enterprise. 

The  following  roles  have  been  identified  for  the  ANSI-IRDS  in  an  AGIS.  They  allow  TDC 
managers  to  build  a dictionary  of  airport  facilities  which  may  be  cross-referenced  and  at  the 
same  time  ensure  data  security,  transfer,  maintenance  and  integrity. 

6.2.1  Naming  of  Data  Entities 

An  airport  is  composed  of  telecommunication,  navigational  and  related  support  equipment 
which  is  associated  with  runways.  Examples  of  these  are  Instrument  Landing  Systems  (ILS), 
Glide  Path  (G/P)  and  Ceilometer  respectively.  There  are  also  navigation  aids  not 
associated  with  runways.  For  example,  Area  and  Airport  Surveillance  Radar  (AASR)  and 
Secondary  Surveillance  Radar  (SSR)  - which  are  located  airside.  Equipment  such  as 
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Approach  Slope  Indicator  Systems  (ASIS)  which  provide  a safe  minimum  wheel  clearance 
over  the  runway  threshold  and  a safe  margin  clear  of  all  obstacles  when  on  final  approach, 
may  be  installed  or  replaced  at  airports.  For  example.  Visual  ASIS  (VASIS)  are  provided 
to  serve  the  approach  to  a runway  when  one  or  more  of  the  following  conditions  exist: 

• the  runway  is  not  equipped  with  electronic  G/P  information  and  is  used  on 
a regular  basis  for  jet  carrier  operations; 

• the  pilot  of  any  carrier  w'ho  may  have  difficulty  judging  the  approach  due  to 
inadequate  visual  guidance  over  water  or  featureless  terrain  or  misleading 
information  produced  by  deceptive  surrounding  terrain  or  runway  slopes; 

• objects  in  the  approach  area  which  may  cause  serious  hazard  to  a carrier 
descending  below  the  normal  approach  path; 

• unusual  turbulence  occurring  in  the  approach  area,  and/or  physical  conditions 
at  either  end  of  the  runway  which  may  present  a serious  hazard  to  a carrier 
which  undershoots  or  overshoots  the  runway  (Air  Navigation  Systems 
Requirements  Branch,  1985). 

Two-bar  VASIS  is  being  phased  out  and  will  cease  to  be  a standard  visual  approach  slope 
indicator  system  on  January  1 , 1995  (Air  Navigation  Systems  Requirements  Branch,  1985). 
In  the  meantime,  Precision  Approach  Path  Indicator  Systems  (PAPIS)  is  an  alternative  to 
VASIS.  This  upgrade  was  carried  out  progressively  at  LBPIA  from  1987  to  1989.  Although 
they  are  no  longer  operational,  the  VASIS  have  not  been  removed  from  the  airside; 
consequently,  their  position  and  attributes  are  maintained  in  the  geographic  database. 

An  AGIS  stores  the  coordinates  and  attributes  of  each  piece  of  equipment.  Database 
queries  on  the  equipment  name,  its  acronym  or  its  replacement  name  cannot  be  performed 
unless  each  entity  in  the  database  is  keyed  with  non-graphic  attributes  to  facilitate  its 
identification;  for  example,  equipment  name,  alternative  name(s)  and  upgrade  name. 
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The  ANSI-IRDS  provides  a mechanism  that  allows  entities  to  be  given  an  access  name,  a 
descriptive  name  and  alternative  names.  Naming  conventions  for  the  format  and  content 
of  data  entity  names  can  be  enforced  by  the  TDC  manager  to  help  establish  consistency 
checking  of  data  throughout  the  organization.  This  results  in  greater  efficiency  through 
reduced  data  handling  as  the  number  of  discrete  data  elements  is  reduced.  It  also  reduces 
confusion  among  both  staff  and  management,  as  communication  is  enhanced  (Newton, 
1987). 

6.2.2  Security 

Airports  GISs  can  explicitly  store  geographic  data  on  the  location  of  airport  facilities.  These 
include  air  terminal  buildings  (ATBs),  underground  tunnels,  access  roads,  bomb  disposal 
areas,  security  locations,  etc.  They  may  also  store  explicit  relations  between  these  features 
and  attribute  data  describing  facilities.  However,  they  cannot  protect  or  secure  airport  data. 

Airports  have  become  targets  for  terrorist  activities  in  recent  years.  As  a result,  data  on 
these  facilities  might  be  classified  as  security  plans  are  based  thereon.  In  addition,  access 
to  hardware  platforms  and  software  tools  must  be  restricted. 

The  ANSI-IRDS  security  module  allows  conventions  on  assigning  security  to  be  defined. 
For  example,  a description  of  what  types  of  personnel  should  have  what  types  of 
permissions  to  read,  write,  add,  modify  or  delete  what  types  of  meta-data  can  be  assigned. 
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6.2.3  Data  Transfer 


TDC  managers  receive  and  disseminate  data  from/to  airport  clientele,  consultants, 
government  investigating  agencies  and  adjoining  municipalities.  Data  may  be  received  or 
transmitted  in  various  formats  and  mav,  or  may  not.  be  created  on  systems  identical  to  those 
of  the  TDC.  Each  system  has  its  own  commands  for  representing  geometric  entities  and 
these  commands  must  be  identified  and  processed  for  a successful  data  conversion.  GISs 
provide  data  conversion  packages  to  handle  formats  provided  by  other  vendors.  However, 
very  few  conversion  packages,  if  any,  provide  a satisfactory'  solution  to  the  conversion  of 
non-standard  geometric  entities;  for  example,  ellipses  and  complex  curves.  Therefore,  most 
conversions  are  carried  out  in  an  ad  hoc  manner. 


The  ANSI-IRDS  standard  provides  mechanisms  for  documenting  non-transferrable 
geometric  elements  between  systems  and  alternative  commands  which  are  used  in  their 
representation.  When  linked  with  an  AGIS,  the  ANSI-IRDS  could  verify  the  representation 
of  entities  in  the  interchange  format  prior  to  conversion  or  dissemination  of  data. 

6.2.4  Data  Management  and  Maintenance 

An  AGIS  contains  relationships  between  entities  which  must  be  preserved  if  integrity  is  to 
be  maintained.  These  relationships  may  have  to  be  changed  in  cases  where  a feature  has 
been  removed,  replaced  or  modified.  Decisions  about  data  and  actions  made  as  a result  of 
these  decisions  need  to  be  recorded  and  preserved.  The  ANSI-IRDS  allows  these  types  of 
decisions  to  be  captured  and  stored  by  using  the  Basic  Functional  Schema  to  extend 


31 


relationships  between  entities,  relationships  and  elements.  The  storing  of  this  information 
can  be  of  value  to  airports  where  there  is  a large  turnover  in  staff  or  in  instances  where  key 
personnel  resign. 

The  ANSI-IRDS  supports  versioning,  which  permits  revision  numbers  to  be  assigned  to 
changing  versions  of  each  entity  as  part  of  the  access  name.  Each  entity  revision  is  stored 
separately  in  the  ANSI-IRDS  as  a separate  entity.  This  means  that  in  TDC  management, 
an  audit  trail  is  provided  on  updates  and  the  history  of  an  entity  can  be  reviewed,  if 
required.  Time  stamping  of  the  data  entities  in  the  AGIS  is  also  achieved  w'ith  the  IRDS 
as  each  entity  accessed  has  meta-attributes  of  system-time  and  system-date  recorded 
automatically. 

6.2.5  Database  Integrity 

Most  GISs  contain  a tool  box  of  commands  which  allow  topologic  relationships  to  be 
established  between  geometric  entities.  Typically,  they  do  not  provide  the  capability  to 
automatically  constrain  relationships  or  provide  for  checking  their  integrity.  For  example, 
on  an  airport,  an  accessway  intersects  a taxiway  but  does  not  intersect  a runway.  An  IRD 
provides  for  data  consistency  checking  rules  to  be  incorporated  into  an  AGIS.  For  a 
particular  entity  type,  the  user  can  define  data  integrity  constraints  and  rules  such  as  direct 
or  associated  relationships  between  an  entity  or  a range  of  values  or  a particular  set  of 
values  that  are  permissible  for  any  instance  of  such  an  entity  in  the  database.  An  example 
of  a constraint  and  rule  is  - storm  pipe-links  to-storm  manhole  and  overt  elevation  of  storm 
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manhole  > invert  elevation  of  storm  pipe. 


6.2.6  Data  Processing 

TDCs  undertake  geographic  information  processing  for  various  airport  groups.  Some  of 
these  processes  are  repetitive  and  include  the  use  of  common  data  sets  and  the  following 
GIS  functions: 


• Integration  of  multiple  geographic  data  sets 

• Network  analysis  - tracing,  shortest  path 

• Proximity  distance 

• Buffering 

• Terrain  slope  computation 

• Point-in-polygon  search 

Often,  in  environments  such  as  the  LBP1A  TDC,  where  on  average  15  requests  for 
information  are  handled  each  day,  by  four  or  five  individuals,  it  is  not  uncommon  to  find 
duplicated  efforts  in  the  processing  of  geographic  data.  An  AGIS  by  itself,  will  not  provide 
the  tools  to  monitor  and  identify  these  duplicated  efforts. 


To  maintain  efficiency  in  a data  processing  environment,  it  is  essential  that  standardized 
procedures  be  developed  and  maintained.  IRD  Schemas  can  be  developed  to  ensure  that 
users  perform  processes  in  a certain  sequence  using  specified  tolerances. 
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7. 


METHODOLOGY 


In  this  Chapter,  the  concept  of  a TDC  is  discussed  and  the  rationale  for  selecting  and 
modelling  the  LBPIA-TDC,  FAP  process  and  the  GIRDS  for  airport  geographic  data  is 
presented. 

7.1  Concept  of  a Technical  Data  Centre 

The  TDC  at  airports  in  Canada  grew  out  of  the  concept  of  establishing  Technical  Drafting 
Centres  for  the  integration  of  Architectural  and  Engineering  functions  for  technical  data 
management.  This  concept  was  supported  by  a feasibility  report  on  Computerized  Drafting 
from  the  National  Facilities  Committee  on  Computer  Applications  in  October  1982  and  a 
pilot  project  was  set  up  in  the  Ontario  Construction  Branch  office  in  Toronto  in  October 
1983  and  was  completed  October  1984  (Airport  Facilities  Branch,  1985). 

The  objective  of  the  pilot  project  was  to  implement  a Technical  Drafting  Centre  which 
would  satisfy  client  drafting  needs  through  direct  lines  of  communication  for  data  exchange, 
centralizing  regional  drafting  management,  optimizing  technology  use  and  application  and 
provide  a formal  information  system  for  ongoing  cost/benefit  analyses. 
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The  pilot  project  proved  successful  as  it  showed  that  the  TDC  concept  was  a cost-effective 
way  to  satisfy  regional  drawing  production  requirements  for  all  regional  clients.  Based  on 
these  results  and  the  realization  that  this  concept  could  further  be  expanded  to  include 
management  for  site/regional  data  as  well  as  site/regional  technical  resources,  TDC 
Implementation  Planning  began  in  January  1986  (Airport  Facilities  Branch,  1985). 

The  TDC  National  Implementation  Program  (NIP)  identified  the  TDC  components  as: 

• data  input  and  collection 

• technical  user/management  committees 

• technical  data  centre  computer  aided  drafting  (CAD)  management 
system 

• data  storage  and  retrieval  and 

• cyclic  review  and  updating  programs. 

The  NIP  concluded  that  the  TDC  management  concept  develops  for  management  and  site 
regional  users,  databases  of  reliable  site  data  which  are  cyclically  updated  (Airport  Authority 
Group,  1988b). 
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7.2  Technical  Data  Centre  and  Geographic  Data  Management 

Table  4 lists  the  geographic  data  currently  managed  by  TDCs  and  updated  by  the  Facility 
Alteration  Permit  (FAP)  process. 


TABLE  4 - Geographic  data  stored  at  Technical  Data  Centres 


Storage  Medium 


Geographic  Data 


Cronaflexes 
Microfilm 
Magnetic  Tape 
Magnetic  Disks 


Leasehold  Property  Boundaries 


Airport  Property  Boundaries 


Zoning  and  Flight  Restrictions 
Planimetric  Features  - roads,  runways,  buildings 
Hydrographic  Features  - rivers,  lakes 
Vegetation 

Utility  Data  Above  and  Below  Ground  - poles, 
hydrants,  manholes 

Pow'er  and  Communication  Data  - direct  buried 
electrical  cables,  telephone  lines 

Ground  and  Noise  Contours 


Geographic  data  in  Table  4 is  currently  stored  in  layered  drafting  files.  These  files  have 


been  found  to  contain  varying  levels  of  accuracy  (1-20  centimetres)  and  content  (Robinson 


and  Sani,  1990).  In  addition,  connected  features  from  adjacent  files  may  contain  different 


graphic  attributes  because  data  integrity  checks  cannot  be  performed  with  the  existing 


software  tools  in  advance  of  file  loading.  Currently,  all  Major  Federal  Airports  as  well  as 


Transport  Canada’s  six  operating  airports  are  in  the  process  of  establishing  or  maintaining 
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TDCs.  One  of  the  established  centres  - Toronto  LBPIA  TDC  is  selected  as  the  site  for 


integrating  GIS  and  IRDS  for  the  following  reasons: 


• The  Toronto-LBPIA  is  a dynamic  site  located  in  Mississauga,  Ontario,  and 
adjoins  the  municipalities  of  Mississauga,  Etobicoke  and  Peel.  It  is  Canada’s 
busiest  airport  and  one  that  is  under  constant  public  scrutiny.  Demands  for 
air  and  land  space  are  immense. 

• The  Toronto-LBPIA  TDC  is  the  most  advanced  in  Canada.  It  is  actively 
collecting  data  on  its  facilities  and  disseminating  data  to  a wide  airport 
clientele  as  shown  in  Figure  7. 

• The  site  employs  a full  time  FAP  officer  who  works  in  conjunction  with  the 
TDC  manager. 

• The  staff  at  Toronto-LBPIA  is  highly  trained  and  understands  GIS  technology. 

• The  site  was  one  of  two  studied  by  ILIM  (Robinson  and  Sani,  1990)  and  is 
conveniently  located  near  the  University  of  Toronto,  Erindale  Campus. 
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Professional  & 
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Development 
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Security 


Toronto  - LBPIA 
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Data 
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Public  Works 
Canada 


Utilities 


Marketing 


Planning 


Car  Rental 
Agencies 


Canadian  Transportation  Accident 
Investigation  and  Safety  Board 


Figure  7 - Typical  users  of  the  LBPIA-TDC 


38 


7.3  Facility  Alteration  Permit  Process 

Updates  to  geographic  data  in  the  TDCs  are  carried  out  through  FAPs,  projects  initiated 
by  the  Land  Use  approval  process  whereby  as-built  data  is  supplied  to  the  TDC  and  by 
cyclical  update  programmes  using  aerial  photography.  This  process  although  implemented 
at  all  Major  Federal  Airports  in  Ontario,  is  operational  only  at  Toronto  - LBPIA. 

A major  function  of  the  FAP  system  is  to  ensure  that  all  tenants,  including  Customs  and 
Immigration,  and  Health  and  Welfare,  concessionaires  and  other  parties  who  intend  to  make 
alterations  on  the  airport  submit  a proposal  to  the  Profit  Centre  Manager  (PCM).  Four 
Profit  Centres  have  been  established  at  Toronto  - LBPIA;  namely,  Air  Terminal  Building 
1 (ATB1),  ATB2,  Airside  and  Groundside.  Proposals  include  a written  request  for  a FAP 
and  design  documents  (architectural,  civil, structural,  mechanical,  electrical)  prepared  by  the 
tenant  together  with  all  necessary  documentation  attached.  The  exact  orientation  of  the 
new/altered  facility  within  any  airport  building  or  on  any  airport  property,  is  also  required 
to  be  shown  (e.g.  column  numbers,  distance  from  existing  walls,  roadways,  and  so  forth). 
On  major  projects,  a commitment  to  provide  as-built  drawings  is  required  as  part  of  the 
submission. 

Once  a FAP  is  obtained,  the  tenant  proceeds  with  construction  in  an  agreed  upon  time 
frame.  On  completion,  as-built  drawings  of  the  new  facility,  if  required,  are  submitted  to 
the  Technical  Data  Centre  (Airport  Authority  Group,  1988a  and  Airport  Construction 
Services,  1982). 
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Database  maintenance  at  airports  is  not  automated.  It  is  a separate  task,  undertaken  by 
TDC  managers  when  time  permits.  In  many  instances,  updates  may  not  be  undertaken 
quickly  and  efficiently  with  the  result  that  users  have  begun  to  question  the  integrity  of  the 
database  (Robinson  and  Sani,  1990). 

The  FAP  process  is  currently  the  process  for  initiating  the  database  maintenance  process 
at  Toronto  - LBPIA.  It  is  the  only  mechanism  through  which  TDC  managers  can  maintain 
their  information  base. 
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8. 


THE  TECHNICAL  DATA  CENTRE  COMPUTER  ASSISTED  DRAFTING 


DATABASE 

The  TDC  CAD  database  was  developed  in  1985  with  the  objective  of  providing  Transport 
Canada  with  current,  consistent  data  at  its  Major  Federal  Airports  and  six  operating 
Regions.  Specifications  for  the  database  design  required  flexibility  for  efficient  CAD  use 
and  structuring  of  data  elements  to  facilitate  low  cost  data  conversion  following  GIS  system 
acquisition  (Sani,  1988  and  McFarlane,  1988).  The  LBPIA  TDC  stores  geographic  data  as 
geometric  primitives  (GPs)  which  are  organized  into  one  of  10  files  (Table  5). 

Each  GP  is  assigned  graphic  attributes  of  display  level,  display  colour,  line  thickness  and  line 
style  and  is  stored  in  both  a binary  graphics  format  and  an  American  Standard  Code  for 
Information  Interchange  (ASCII)  format.  GPs  in  the  ASCII  format  have  associated  with 
them  the  National  Topographic  Senes  (NTS)  feature  code  as  an  attribute,  but  this  attribute 
is  not  stored  in  the  binary  graphic  files  (Sani,  1988). 

There  is  limited  data  structuring  in  the  database.  GPs  stored  are  points,  lines  and  to  a 
lesser  extent  polygons  (e.g.  buildings  and  wooded  areas)  with  no  connectivity,  continuity  or 
spatial  relationships  explicitly  represented  in  the  data  structure.  This  structure,  although 
acceptable  for  CAD  applications,  is  clearly  unacceptable  for  the  management  of  Transport 
Canada’s  information  resource. 
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TABLE 5 - LBPIA  geographic  data  files 


File  Name 

Example  of  Features  Stored 

Civil  Utility  Above  Ground 

Catch  Basin,  Manhole,  Hydrant 

Civil  Utility  Under  Ground 

Septic  Tank,  Storm  Pipe 

Control  and  Boundary 

Monument,  Airport  Property  Boundary 

Electrical  Utilities  Above 

Ground 

Antenna,  Apron  light,  Electri- 
cal manholes 

Electrical  Utilities  Under 

Ground 

Telephone  cable.  Duct,  Trans- 
former 

Hydrography 

Creek,  Ditch,  Lake,  Swamp 

Planimetnc 

Road,  Bridge,  Sidewalk 

Topographic 

Contour,  Spot  Elevation 

Vegetation 

Wooded  Area,  Tree,  Scrub 

Zoning  and  Flight  Path 
Restrictions 

Registered,  ICAO,  Restricted 

Information  resource  management  relies  on  current  and  up-to-date  information  to  be 
effective.  Attempts  aimed  at  keeping  databases  up-to-date  at  LBPIA,  by  means  of  the  FAP 
process  have  failed,  due  to  the  lack  of  human  resources  required  to  manually  input  the  as- 
built  data  (Robinson  and  Sani,  1990).  A more  automated  approach  is  required.  The 
GIRDS  model  provides  support  for  this  automation  by  linking  the  FAP  process  to  the 
management  of  geographic  data. 
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9. 


THE  FACILITY  ALTERATION  PERMIT  DATA  MODEL 


This  Chapter  describes  the  E-R  model  developed  for  the  FAP  process  at  Toronto  Lester  B. 
Pearson  International  Airport  described  in  Chapter  7.  In  the  following  discussion,  entities 
are  highlighted  and  relationships  are  highlighted  and  underlined. 

The  model  identifies  the  tenant  as  commencing  the  FAP  process  by  obtaining  a TDC  Work 
Request  Form  which  is  completed  and  passed  to  the  TDC  (Figure  8).  Cardinalities  of  1 : N 
and  N:1  respectively  are  assigned,  as  there  is  one  work  request  per  TDC  w ork  request  form. 


Work  request  is  modelled  as  the  parent  of  the  children  general  information,  TDC  w ork  com- 
ments, details  of  request  and  request  type  by  use  of  the  tea  relationship  with  cardinalities 
of  1:1.  An  isa  relationship  is  also  used  to  link  the  parent  request  type  with  children  TDC, 
art  and  FAP,  which  describe  the  type  of  request.  Upper  and  lower  bound  cardinalities  of 
0:1  are  assigned  respectively  indicating  that  a request  may  contain  a minimum  of  zero  and 
a maximum  of  1 request  type.  The  entity  general  information  is  further  modelled  to  show 
that  the  name  of  the  individual  making  the  request  is  included  as  pan  of  the 
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Notat  Text:  placement  by  E-R  Designer,  (Clien  and  Associates,  1909) 


general  information  on  the  work  request.  A cardinality  of  1:1  is  assigned. 


The  TDC,  having  received  a Work  Request  Form  from  the  tenant,  accesses  the  databases 
to  determine  the  availability  of  the  data.  Databases  stored  by  the  TDC  are  geographic  and 
building  structure  and  are  modelled  by  a parent-child  relationship  of  cardinalities  1:1,0: 1. 
The  Building  structure  database  may  contain  structural,  mechanical,  utilities,  electrical  and 
architectural  databases  and  therefore  is  linked  to  the  parent  building  structure  with  an  isa 
relationship  of  cardinalities  1 : 1 :0: 1 (Figure  9). 

Databases  are  used  bv  data  processing  to  provide  information  to  the  tenant.  Cardinalities 
are  N:N  and  1:1  respectively,  as  many  processes  may  be  run  on  the  databases  to  produce 
the  requested  information  set  (Figure  9). 

Information  produced  by  the  TDC  is  used  for  preparing  documents  which  are  submitted 
with  the  FAP  Application.  Cardinalities  are  N:N  and  N:1  respectively.  The  FAP application 
is  submitted  to  the  tenant's  PCM,  who  in  turn  forwards  it  (tables  request)  to  a Technical 
Review  Committee  (TRC). 
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Pigure  9 - Databases  stored  by  the  Technical  Data  Centre 
Note:  Text  placement  by  E-R  Designer,  (Chen  and  Associates,  1989) 


Assigned  cardinalities  of  1:1,  as  shown  in  Figure  10,  indicate  that  each  application  is 
reviewed  by  a PCM  and  a TRC. 

The  application,  having  been  reviewed  by  the  TRC  is  forwarded  to  the  Manager  of  Airport 
Development  who  creates  a project  file  and  identifies  a LBPIA  project  team  to  study  the 
FAP  application  in  detail.  Cardinalities  of  1:1  are  assigned.  The  project  team  generates 
comments  which  are  delivered  to  the  TRC.  The  TRC  then  makes  a recommendation  which 
is  communicated  to  the  tenant  (Figure  11).  On  approval  of  the  FAP  the  tenant  prepares 
an  alteration  schedule  which  specifies  an  alteration  period  (Figure  12). 

During  the  alteration  period,  regular  inspection  is  undertaken  by  the  FAP  officer  to  ensure 
compliance  (IKAP/FAP  officer- issue-inspection  report)  (Figure  12).  A cardinality  of  1:N 
is  assigned  which  indicates  that  several  inspection  reports  may  be  provided  to  a contractor- 
tenant  during  the  construction  period. 

On  completion  of  the  alteration,  the  contractor-tenant  finalize  as-built  drawings  which  are 
entered  in  the  TDC  for  the  purpose  of  updating  the  existing  databases  (as-built  drawing- 
entered  in-TDC).  Since  as-built  drawings  contain  overlays  showing  above  ground  and 
underground  features,  electrical  distribution  and  so  forth,  cardinalities  of  N:1  are  assigned 
(Figure  12). 
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Figure  10  - The  FAP  application  submitted  to  the  Profit 
Note:  Text  placement  by  E-R  Designer,  (Chen  and  Assoc 
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Note:  Text  placement  by  E-R  Designer,  (Chen  and  Associates,  1989) 


9.1  FAP  Attributes 


A number  of  attributes  were  identified  for  the  FAP  entities  during  the  modelling  process. 
These  attributes,  listed  in  Table  6,  indicate  that  it  is  possible  to  select  a key  identifer,  such 
as  a FAP  number,  to  link  DBMS  attribute  tables  with  spatial  data. 

TABLE  6 - FAP  attributes 


Entity  Name 

Attributes 

Details  of  request 

Capital  number 

IKAP  number 

PWC  number 

Required  date 

Drawing  number 

Contract  number 

TDC  w'ork  comments 

Date  sent  out 

Work  order  number 

Name  of  consultant 

Request  completed  by 

Date  of  completion 

General  information 

Project  title 

Designator 

Phone  number 

Date 

Name 

Surname 

Given  name 

FAP 

FAP  number 

Profit  Centre  Manager 

Surname 

Given  name 
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TABLE  6 - FA P attributes  (cont.) 


Entity  Name 

Attributes 

Airport  Development 
Manager 

Surname 

Given  name 

Project  file 

Number 

FAP  document 

Reference  number 

Transport  Canada 
document 

Reference  number 

Tenant 

Surname 

Given  name 
Address 

Telephone  number 

Alteration  schedule 

Start  date 

End  date 

Alteration  period 

Number  of  months 

IKAP  officer 

Surname 

Given  name 
Telephone  number 

Inspection  report 

FAP  number 
Report  number 

Contractor/tenant 

Surname 

Given  name 

Alteration 

FAP  number 
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TABLE  6 - FAP  attributes  (eont.) 


Entity  Name 


As-built  drawing 


Attributes 


Drawing  number 

Consultant  agreement  number 

Project  date 

Project  number 

Sheet  number 

Scale 

Description 
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10.  THE  GEOGRAPHIC  DATA  MODEL 


The  geographic  data  model  (GDM)  is  organized  to  reflect  a logical  view  of  systems  as  they 
exist  at  the  airport.  It  is  based  on  the  E-R  approach  to  modelling  spatial  databases  which 
has  been  successfully  adopted  by  Armstrong  and  Densham,  1990;  Calkins  and  Marble,  1987; 
and  Robinson  and  Zhang,  1988.  Entities  at  the  highest  level  in  the  model  are  treated  as 
complex  feature  systems  which  may  be  decomposed  into  feature  systems  and  then  into 
features  at  the  lowest  level.  Features  are  represented  by  their  fundamental  dimensional 
(FD)  entities  (i.e.  geometric  primitives)  consisting  of  points,  nodes,  complex  lines  and  poly- 
gons, each  of  which  is  built  from  a set  of  coordinate  triplets  (Armstrong  and  Densham, 
1990).  The  model  enables  high-level  entities  to  obtain  their  FD  representation  through 
hierarchical  aggregation. 

The  GDM  views  the  geographic  database  as  the  parent  of  three  distinct  types  of  airport 
operations  - Airside,  Groundside  and  Prosaic  (McFarlane,  1990).  In  turn,  these  operations 
are  modelled  as  complex  feature  systems.  This  approach  can  be  contrasted  to  the  view  of 
the  LBPIA-TDC  which  is  based  on  the  three  major  airport  operating  systems  - Airside, 
Groundside  and  Industrial  - in  which  airport  features  are  not  easily  represented  due  to  the 
complexity  and  overlapping  of  geographic  features  within  each  system.  For  example, 
geographic  features  in  the  groundside  drainage  system,  such  as  storm  sewers  and  ditches, 
cross  into  the  airside  system. 
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In  the  GDM,  airside  complex  feature  systems  encompass  all  geographic  features  which  are 
common  to  an  airfield  feature  system,  such  as,  runways,  taxiuays  and  aprons.  Airport 
Prosaic  Systems  are  complex  feature  systems  which  represent  all  feature  systems  common 
to  both  Airside  and  Groundside.  These  may  include  storm,  utility  and  boundary  feature 
systems.  Groundside  complex  feature  systems  include  only  feature  systems  that  are 
consistently  located  on  the  groundside  of  airports,  such  as  administrative  and  catering 
facilities,  fuel  farms  and  power  houses. 

10.1  Airside 

In  Figure  13,  the  complex  feature  system  airside  is  a parent  of  the  airfield  feature  system. 
An  isa  relationship  exists  between  the  parent  entity  airfield  and  the  children  feature  entities 
runway,  taxiway,  apron  and  unpaved  area.  Cardinalities  of  1:N  are  assigned  as  LBPIA 
airfield  contains  many  of  the  above  child  entities.  Runwaysare  connected  to  many  taxiways 
which  joins  aprons.  Cardinalities  of  N:N  are  assigned  for  the  relationship  apron -adjacent 
to  -unpaved  area  as  is  the  case  at  the  end  of  aprons  and  at  intersections  of  taxiways. 
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10.1.1  Runwav  Linkages 

At  airports,  each  runway  is  zoned.  There  are  tour  types  of  zoning,  namely, 
restrictive,  registered,  operational  and  ICAO  (the  International  Civil  Aviation 
Organization).  Cardinalities  of  1 : 1,0: 1 indicate  as  illustrated  in  Figure  14  that  the  existence 
of  a runway  does  not  imply  the  existence  of  one  or  more  types  of  zoning. 

Registered  zoning  defines  the  runway  strip,  take  off  and  approach  surface,  obstacle 
limitation  surface  and  the  transitional  surface.  A parent-child  relationship  is  used  to  model 
the  registered  zoning.  Each  child  is  linked  to  its  parent  with  cardinalities  of  1:1,0:N 
indicating  that  both  runway  ends  may  have  registered  zoning. 

The  restrictive  feature  entity  is  modelled  as  parent  of  navigational  aids  and  waste  disposal 
area  by  use  of  the  isa  relationship  with  cardinalities  of  1 : 1 ,0:N respectively.  Navigational 
aids  is  further  decomposed  by  modelling  it  as  the  parent  of  VASIS,  PAPIS,  low  intensity- 
light  bars,  high  intensity  light  bars  and  instrument  landing  system  with  cardinalities  of 
1: 1,0:1.  Each  Navigational  Aid  is  linked  to  the  centre-line  of  the  runway  which  is  contained 
in  the  runway  approach  path.  The  centre-line  of  the  runway  is  defined  by  two  threshold 
points  as  shown  in  Figure  14,  hence  the  cardinality  of  1:N,  where  N = 2.  Instrument 
Landing  System  is  modelled  as  the  parent  of  a number  of  feature  entities,  namely,  outer 
marker,  middle  marker,  glide  path,  back  beam  marker  and  back  beam  antenna  with 
cardinalities  of  1:1.  Each  of  these  feature  entities  are  associated  with  their  children  - 
building  and  antenna  - through  isa  relationships,  each  with  a 1:1  cardinality. 


57 


HAS  > , RUNWAY  H1 <CW#f„0T*  J> J TAXIWAY 


58 


Figure  14  - Runway  centre-line  definition 


The  ICAO  zoning  is  viewed  as  the  parent  of  ICAO  obstacle  limitation  surface.  A relation 
of  1:N  is  established  indicating  that  this  zoning  is  applicable  to  both  ends  of  the  runway,  as 
changes  in  weather  conditions  may  determine  which  end  of  a runway  is  used  for  take-off  and 
landing.  ICAO  obstacle  limitation  surfaces  prevent  obstacles  from  intruding  into  approach 
path.  Relationships  as  shown  in  Figure  15  are  expressed  as  1:N  and  N:1  respectively. 

An  Obstacle  isa  vegetation,  topography,  building,  pole  and  antenna.  Both  vegetation  and 
topography  are  represented  individually  as  an  aggregation  of  child  entities  (in  the  case  of 
topography  not  shown  in  the  GDM)  and  hence  the  cardinalities  of  1 : 1 ,0: 1 . Entities  building, 
pole  and  antenna  are  assigned  cardinalities  of  l:l,0:Nas  many  of  these  features  are  located 
airside.  Vegetation,  as  shown  in  Figure  15,  is  the  parent  of  feature  entities  scrub,  wooded 
area  and  tree  while  topography  is  described  by  contours  with  cardinalities  of  1:N. 

Operational  zoning  which  exists  only  in  the  absence  of  registered  zoning,  does  not  occur  at 
LBPIA.  Therefore,  this  feature  entity  is  not  decomposed  in  the  GDM. 

Runway  is  associated  with  many  lighting  systems.  These  lighting  systems  are  parents  of 
edge,  inset  and  approach.  Lower  and  upper  bound  cardinalities  of  0:N  are  established  for 
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Figure  15  - Airside  vegetation 

Not  Text  plncnmonl  l>y  K-  U Dunlgnor  , (Clien  mid  Aimoc  I n ton  , I *111*1 ) 


edge  and  inset  as  shown  in  Figure  16,  as  some  airports  do  not  have  these  lighting  systems 
for  the  following  reasons: 


• only  local  commercial  airports  licensed  for  night  operations  are  equipped  with 
edge  lighting;  for  example,  the  turf  runway  at  Nluskoka  airport  does  not  have 
edge  lighting. 

• only  runways  with  category  II  status  are  equipped  with  inset  lighting  which 
allow  operation  under  adverse  weather  conditions.  In  Ontario,  LBPIA  is  the 
only  airport  which  has  inset  lighting  on  runways. 


Both  edge  and  inset  lighting  systems  are  represented  as  feature  entities  in  the  model.  A 
low'er  and  upper  bound  cardinality  of  1:1  is  assigned  to  approach  lights  as  these  exist  at  all 
airports.  Approach  lights  are  further  decomposed  through  an  isa  relationship  to  link  existing 
feature  entities  - high  intensity  approach  bars  and  low  intensity  approach  bars  - with  1:N 
relationships.  These  feature  entities  are  defined  in  Figure  14  through  parent-child  linkages 
with  the  entities  navigational  aids  and  restrictive  zoning. 

10.1.2  Taxiway  Linkages 

As  shown  earlier  in  Figure  13,  the  model  describes  taxiwavsas  connected  to  runways  with 
a 1:N  cardinality.  Taxi  ways  are  also  viewed  as  joining  aprons  and  intersecting  accessways 
with  cardinalities  of  1:N.  Many  accessways  are  linked  wdth  each  road,  hence  a cardinality 
of  N:  1. 
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Figure  16  - Runway  lighting  system 
Note:  Text  placement  by  E-R  Designer,  (Chen  and  Associates,  19H9) 


10.1.3  Apron  Linkages 


Apronsare  represented  in  the  model  as  joining  taxiways (Figure  13).  They  are  also  viewed 
as  adjoining  air  terminal  buildings  and  therefore  a relationship  connection  of  N:  1 is 
assigned. 

10.1.4  Unpaved  Area  Linkages 

Unpaved  area  is  modelled  as  adjacent  to  aprons  with  N:N  cardinality.  No  further 
decomposition  of  this  feature  entity  is  undertaken  in  the  model. 

10.2  Prosaic  System 

A Prosaic  system  on  the  airport  is  viewed  as  a parent  complex  feature  system  with  children 
Storm  Drain,  Transportation,  Utility  and  Land  Related  Information  which  may  or  may  not 
be  represented  at  all  airports.  Upper  and  lower  bound  cardinalities  assigned  to  this  isa 
relationship  are  1:1, 0:1  as  illustrated  in  Figure  17. 

10.2.1  Storm  Drain  Linkages 

The  feature  system  Storm  Drain  is  the  parent  of  the  feature  entities  ditch  and  storm  sewer 
with  cardinalities  of  1 : 1 ,0: N.  Ditch  drains-into  storm  culvert  which  connects-with  storm 
pipe.  Cardinalities  of  N:1  and  1:1  are  assigned  respectively.  Linkages  between  storm 
culvert  and  storm  pipe  with  storm  sewer  are  obtained  through  the  isa  relationship  with 
cardinalities  of  1:1,  with  storm  sewer  as  parent.  A storm  pipe  is  viewed  as  providing  a 
linkage  to  a storm  manhole.  Many  storm  manholes  are  required  for  draining  a road,  hence 


63 


64 


Figure  17  - Prosaic  system 

Note:  Text  placement  by  E-R  Designer,  (Chen  and  Associates,  1989) 


a N:  1 cardinality. 


A N:  1 relationship  - ditch-runs-into  - is  established  between  the  feature  entities  ditch  and 
creek.  A creek  is  viewed  as  flowing-under  many  bridges  and  bridges  are  located  on  (is-on) 
roads  (Figure  17).  There  is  no  further  decomposition  of  the  feature  entities  ditch,  creek, 
bridge,  storm  manhole,  and  storm  pipe.  Therefore,  they  are  linked  directly  to  their 
fundamental  dimensional  entities  (FDEs)  through  isa  relationships  with  cardinalities  of  1:1. 

10.2.2  Transportation  Linkages 

The  transportation  feature  system  is  composed  of  off-street  sidewalk,  on-street  sidewalk  and 
road  feature  entities  as  show  n in  Figure  17.  On-street  sidewalks  are  adiacent-to  roads  with 
a cardinality  of  N:l.  Since  many  roads  are  viewed  as  crossing  many  Ontario  Hydro  power 
lines,  a cardinality  of  N:N  is  assigned. 

10.2.3  Utility  Linkages 

The  high-level  system  entity  utility  is  decomposed  into  feature  entities  gas,  w'ater,  power, 
and  communication  through  an  ea  relationship  with  cardinalities  of  1: 1,0:1.  The  entity 
Utility  is  related  to  building  by  the  relationship  connected-to  w'ith  a cardinality  of  1:1.  A 
building  on  an  airport  is  viewed  as  adjoining  many  parking  areas  (1:N)  which  are  accessed: 
by  a road  (N:l).  An  example  of  this  may  be  seen  at  the  LBPIA  Administration  building. 
The  entities  gas  and  communication  are  not  modelled  further  due  to  the  complexity  of  the 
model  in  its  present  form.  Relationships  are  established  however  for  the  entities  water  and 
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power. 


Water  is  distributed-bv  water  pipes  w hich  are  viewed  as  linked  to  hydrants.  Cardinalities 
of  1:N  are  assigned  as  shown  in  Figure  18. 

Power  is  provided-bv  Ontario  Hydro  power  lines  with  a cardinality  of  1:N.  Ontario  Hydro 
power  line  is  the  parent  of  feature  entities  pole  and  power  cable  with  cardinalities  ofl:l,0:N 
and  1:1  respectively.  The  former  low-er  bound  cardinality  indicates  that  power  lines  could 
exist  without  poles  as  is  the  case  on  the  airside.  The  entity  pole  was  earlier  described  in 
Figure  15  as  a child  of  the  feature  entity  obstacle  associated  with  the  airside. 

Power  cables  are  accessed-through  a cable  manhole  and  are  also  buried-adiacent-to  Bell 
Canada  cables  on  the  airport.  Bell  Canada  Cables  are  buried  in  a cable  duct  w hich  run  into 
cable  manholes  with  cardinalities  of  N : 1 and  1:N  respectively.  Finally,  a Bell  Canada  cable 
is  identified  by  many  cable  markers  and  therefore  a cardinality  of  1:N  is  assigned  as  shown 
in  Figure  18. 

10.2.4  Land  Related  Information  Linkages 

The  GDM  describes  the  feature  entity  boundary  as  a child  of  the  feature  system  entity  land 
related  information.  As  LBP1A  has  a defined  boundary,  a 1:1  cardinality  is  assigned. 
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Note:  Text  placement  by  E-R  Designer,  (Chen  and  Associates,  1989) 


Boundary  is  the  parent  of  feature  entities  international,  field,  lease-property, municipal,  and 
airport  properly  with  a cardinality  of  1:1. 0:1  on  the  first  four  entities  and  1:1  on  the  latter 
(Figure  19). 

Lease-property  boundaries  are  connected  to  form  lots.  Cardinalities  of  N:1  are  assigned. 
Lots  are  leased  by  tenants  which  is  an  entity  in  the  FAP  process  described  earlier.  A Lot 
encloses  buildings  and  a cardinality  of  1:N  is  assigned  as  many  buildings  may  be  on  a single 
lot,  but  a single  building  cannot  occupy  more  than  one  lot. 

Airport  property  boundary  is  viewed  as  being  defined  bv  boundary  segments  which  are 
defined  by  survey  bars.  On  all  airport  boundary  surveys,  these  survey  bars  are  coordinated 
from  the  airport  control  network.  The  airport  control  networkis  composed  of  a horizontal 
and  vertical  network.  A parent-child  relationship  with  cardinalities  of  1: 1,0:1  are  assigned. 

10.3  Groundside 

On  the  groundside  of  an  airport,  the  following  complexes  exist  - administrative  facilities, 
power  house  and  fuel  farm.  These  are  modelled  as  feature  entities  and  children  of  the 
complex  feature  system  entity  groundside. 

Administrative  facilities  are  further  decomposed  through  the  isa  relationship  into 
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Figure  19  - Land  related  information 
Note:  Text  placement  by  K-R  Designer,  (Chen  and  Associates,  1989) 


catering  facilities,  administrative  building  and  maintenance  garage  (Figure  20).  All  feature 

entities  are  then  linked  with  cardinalities  of  1:1  to  their  FD  representations  through  parent- 
child  relationships. 

The  feature  entity  powerhouse  is  modelled  as  being  adjacent  to  many  transformers  which 
connect-to  many  power  cables,  hence  cardinalities  of  1:N  and  N:N  respectively. 

Fuel  farms  are  decomposed  through  an  isa  relationship  into  a fuel  farm  complex  which 
store  fuel  tanks.  Cardinalities  of  1:1  and  1:N  are  assigned  respectively.  Fuel  tanks  are 
linked  to  fuel  lines  and  are  also  surrounded  by  dikes,  hence  the  cardinalities  ofN:N  and 
N : 1 respectively. 

10.4  The  Spatial  Model 

Each  feature  entity  is  mapped  to  a FDE  of  point,  node,  line,  complex  line  or  polygon 
(Armstrong  and  Densham,  1990).  Figure  21  shows  the  relationships  between  these  entities. 

The  spatial  model  describes  a coordinate  triplet  as  the  parent  of  point  and  node.  Points 
represent  features  which  are  cartographically  displayed  as  symbols.  Many  nodes  connect  to 
form  many  complex  lines.  A cardinality  of  N:N  is  assigned.  Complex  line  is  the  parent  of 
line,  curve  and  approximate  curve. 
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Note:  Text  placement  by  E-lt  Designer,  (Chen  and  Associates,  19H9) 


Cardinalities  of  1: 1,0:1  indicate  that  a complex  line  could  be  built  from  any  child  or 
combination  of  children.  Attributes  associated  with  FDEs  are  given  in  Table  7. 


Many  complex  lines  define  a boundary  of  a feature.  These  boundary  of  features  are  then 
concatenated  to  form  polygons.  Cardinalities  of  N:N  are  assigned.  Examples  of  feature 
entities  mapped  as  polygons  are  runway,  taxi  way,  apron  and  so  forth. 

Table  7 - Attributes  of  fundamental  dimensional  entities 

Fundamental  Dimensional  Entity  Attribute 


Point 

Point-Identification  (ID) 

Node 

Node-ID 

Line 

From-Node 

To-Node 

Curve 

Radius 

Centre 

Approximate  Curve 

Deflection  angle 

Chord  length 

Complex  line 

Left 

Right 

Polygon 

Area 
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10.5  Attributes 


Attributes  are  associated  with  each  entity.  A complete  listing  of  these  could  not  be 
presented  due  to  the  volume  of  information;  consequently,  only  attributes  of  one  feature 
entity  from  each  category  of  complex  feature  systems  is  presented  in  Table  8. 


Table  8 - Example  of  feature  entity  attributes 


Complex  System  Name  Entity  Name  Attributes 


Airside 


Prosaic 


Groundside 


Runway  Bearing 

Classification 
Construction  date 
Declination 
Length 

Pavement  load 
Rating 
Surface  type 
Width 

Storm  pipe  Diameter 

Flow  direction 
Invert  elevation 
Length 
Material 
Overt  elevation 
Width 


Administrative  Address 

Building  Heating,  ventilation  and  air 

conditioning  (HVAC)  system  type 

Material 

Number  of  storeys 
Occupancy 
Security  system 
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10.6  Spatial  Relationships 

Table  9 lists  spatial  relationships  identified  during  conceptual  modelling.  These  spatial 
relationships  confirm  that  geographic  information  system  processing  is  a necessary 
requirement  at  airports.  For  example,  the  relationships  is-in  and  intersect  suggest  that 
point-in-polygon  and  polygon  overlay  processing  are  required  for  solving  complex  queries 
or  forming  the  database  to  be  consistent  with  the  model  and  subsequent  updates. 


Table  9 

- List  of  spatial  relationships 

Spatial  Relationships 

connected-to 

linked-to 

Symmetric  Relationships 

is-in 

is-on 

outside 

encloses 

contain 

intersect 

cross 

adjacent-to 

adjoin 

enclosed-by 
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10.7  The  GIRDS  Data  Model 


Two  connections  are  possible  to  link  the  FAP  and  GDMs  to  form  the  GIRDS  data  model. 
One  connection  is  through  the  parent-child  relationship  established  for  database  in  which 
the  entity  geographic  was  a child  of  the  entity  database.  The  second  link  occurs  in 
modelling  the  high-level  entity  land  related  information.  Here  the  entity  lot  is  leased  bv 
tenant  in  the  FAP  model. 


10.8  Statistics  on  the  GIRDS  Data  Model 

Table  10  provides  statistics  on  the  GIRDS  data  model.  It  shows  that  of  the  378  constructs 
used  in  the  model,  approximately  66%  are  represented  by  entities  and  relationships.  A 
further  34%  comprise  parent-child  relationships. 

Table  10  - GIRDS  statistics 


Description  Number 

Constructs  378 

Entities  167 

Geographic  entities  126 

Relationships  84 

ISA  127 


Table  11  provides  statistics  on  the  FDEs.  These  numbers  show  that  91  entities  are  mapped 
directly  to  the  FDEs  of  which  approximately  44%  are  polygons  and  29%  complex  lines. 
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Table  11  - FDE  statistics 


Description 


Number 


Point 


16 


Nodes 


Lines 


4 


Complex  Lines 


26 


Polygons 
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10.9  Observations:  Spatial  Data  Representations  with 
E-R  Models 

A couple  of  observations  can  be  made  while  modelling  spatial  data  on  airports.  Firstly,  the 
parent-child  relationship  (isa),  an  extension  of  the  E-R  model,  is  a necessary  construct  for 
the  modelling  of  spatial  relationships.  For  example,  the  FDE  coordinate  triplet  is  the 
parent  of  node  and  point.  Nodes  connect  to  form  a complex  line  which  is  the  parent  of 
FDEs  line,  curve  and  approximate  curve.  These  FDEs  are  then  linked  to  geographic 
features  through  isa  relationships.  It  is  evident  therefore  that  the  linking  of  geographic 
features  to  spatial  relationships  could  not  be  accomplished  in  E-R  modelling  without  the  isa 
construct.  The  parent-child  relationship  also  allows  greater  flexibility  in  modelling 
relationships  and  permitted  hierarchical  aggregation. 

Secondly,  two  entities  require  special  consideration  when  mapped  to  FDEs.  These  are 
runways  and  contours.  Runways  are  usually  identified  by  a number.  For  example  runw'ay 
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15L-33R  indicates  that  one  end  of  the  runway  is  at  an  azimuth  of  150°  while  the  other  is 
at  330°.  L and  R,  left  and  right  indicates  that  this  is  one  of  two  parallel  runways.  15L 
therefore  is  the  left  hand  runway  to  the  aircraft  on  a 150°  heading.  As  such,  it  was 
desirable  to  assign  the  cardinality  between  runway  and  polygon  as  N:  1 where  N = 2. 
Contours  provide  a slightly  different  problem.  Normally,  contours  when  modelled  from  a 
cartographic  view-point  are  viewed  as  complex  lines.  However,  contours  by  their  definition 
are  lines  of  constant  elevation  and  in  fact  close  on  themselves.  In  most  surveying 
applications,  contours  are  used  as  polygons  in  volume  computations  and  cut  and  fill  analysis. 
As  information,  rather  than  data,  is  the  primary  requirement  at  airports,  it  is  natural  to 
model  contours  as  polygons. 
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11.  THE  GEOGRAPHIC  INFORMATION  RESOURCE  DICTIONARY  SYSTEM 

Conversion  of  the  airport  GDM  to  the  ANSI-IRDS  involved,  as  a first  step,  re-defining  the 
data  model  in  terms  of  an  E-R-A  model  in  order  that  entity-types  and  relationship-types  are 
easily  identified.  Next,  an  empty  IRD  had  to  be  created  and  the  IRD  Schema  defined  pnor 
to  compiling  the  ANSI-IRDS  commands. 

11.1  Populating  the  IRD 

The  IRD  is  populated  in  a top-down  manner.  As  a first  step,  this  requires  converting  the 
E-R  diagram  to  an  E-R-A,  GIRDS  diagram  (Law',  1988). 

11.1.1  Conversion  to  an  E-R-A, GIRDS  Diagram 

The  E-R-A,  GIRDS  diagram,  unlike  the  E-R  diagram  identifies: 

• the  direction  of  flow  between  entities, 

• the  hierarchy  of  entities. 

• entity-types  and  relationship-types  associated  with  each  entity  and  relationship; 
and 

• entities  and  relationships  used  in  describing  the  IRD. 

Figures  22  and  23  illustrate  these  concepts. 
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RELATIONSHIP-TYPE:  ENTITY-TYPE: 
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At  the  FAP  level,  (Figure  22),  there  is  no  hierarchy  of  entities.  Each  entity  is  assigned  a 
entity  type,  person  or  object.  Meta-entity  type  person  refers  to  entities  such  as  tenant,  TRC, 
project  manager  and  so  forth.  Meta-entit>  type  object  is  used  to  identify  entities  such  as 
alteration  schedule,  documents,  as-built  drawings  and  so  forth.  Relationship-types  person- 
obtains-object  and  object-is-a-parent-of-object  are  established  for  the  entities  - database  and 
geographic. 

At  the  Geographic  level,  the  hierarchy  of  entities  are  described  as  complex  feature  systems, 
feature  systems  and  features.  The  entity,  geographic  (Figure  23),  which  is  assigned  an  entity- 
type,  object,  is  the  parent  of  the  complex  feature  systems  - airside,  prosaic  system  and 
groundside.  Entity-types  are  therefore  assigned  to  these  entities  as  well  as  a relationship- 
type  of  object-is-a-parent-of-complex-feature-system. 

11.1.2  Creating  an  Empty  IRD 

Once  the  E-R  to  E-R-A  model  conversion  is  complete,  the  next  step  is  to  create  an  empty 
IRD  and  associate  with  it  the  Basic  Functional  Schema.  This  process  could  be  carried  out 
either  interactively  or  through  batch  processing  using  the  IRD  commands  to  create  the  IRD 
Schema  and  define  the  IRD. 

11.1.3  GIRDS  Schema  Definition 

This  section  provides  an  example  of  the  Schema  definition  used  to  support  meta-data  for 
the  GIRDS.  It  should  be  noted  that  within  the  IRD,  each  entity-type  name  and  entity  name 
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must  be  unique. 


Table  12  lists  the  ANSI-IRDS  commands  used  to  define  the  IRD  Schema  for  the  section 
of  the  airport  GDM  shown  in  Figure  23.  These  commands  provide  for  the  definition  of 
entity-types  and  relationship-types  in  the  IRD  Schema. 
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Table  12  - Schema  definition 


/*  entity  type  definition  */ 

add  meta-entity  object  meta-entity-type  = entity-type; 
add  meta-entity  complex-feature-system 
meta-entity-type  = entity-type; 
add  meta-entity  feature-system 
meta-entity-type  = entity-type; 
add  meta-entity  feature  meta-entity-type  = entity-type; 

/*  relationship-class-type-defmition  */ 

add  meta-entity  is-a-parent-of 

meta-entity-type  = relationship-class-type; 

/*  relationship  type  definition:  parent-child  */ 

add  meta-entity  object-is-a-parent-of-complex-feature-system 
meta-entity-type  = relationship-type; 
add  meta-entity 

complex-feature-system-is-a-parent-of-feature-system 
meta-entity-type  = relationship-type; 
add  meta-entity  feature-system-is-a-parent-of-feature 
meta-entity-type  = relationship-type; 
add  meta-entity  feature-is-a-parent-of-feature 
meta-entity-tvpe  = relationship-type: 

/*  relationship  type  definition:  feature-feature  */ 

add  meta-entity  feature-connected-to-feature 
meta-entity-type  = relationship-type; 
add  meta-entitv  feature-joins-feature 
meta-entity-type  = relationship-type: 
add  meta-entity  feature-apron-adjacent-to-feature 
meta-entity-type  = relationship-type: 

/*  relationship-type  associated  with 
relationship-class-type  */ 

add  meta-relationship 

object-is-a-parent-of-complex-feature-system 
member-of  is-a-parent-of; 
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Table  12  - Schema  definition  (cont.) 


add  meta-relationship 

complex-feat  ure-system-is-a-parent-of-feature-system 
member-of  is-a-parent-of; 

add  meta-relationship 

feature-system -is-a-parent-of-feature 
member-of  is-a-parent-of; 

add  meta-relationship 

feature-is-a-parent-of-feature 
member-of  is-a-parent-of; 

/*  relationship-type  positional  definition  */ 

add  meta-relationship 

object-is-a-parent-of-complex-feature-system 
connects  object  position  = 1: 

add  meta-relationship 

object-is-a-parent-of-complex-feature-system 
connects  complex-feature-system  position  = 2; 

add  meta-relationship 

complex-feature-system-is-a-parent-of-feature-system 
connects  complex-feature-system  position  = 1; 

add  meta-relationship 

complex-feature-system-is-a-parent-of-feature-system 
connects  feature-system  position  = 2; 

add  meta-relationship 

feature-system-is-a-parent-of-feature 
connects  feature-system  position  = 1; 

add  meta-relationship 

feature-system-is-a-parent-of-feature 
connects  feature  position  = 2; 


11.1.4  GIRDS:  IRD  Definition 


Once  the  IRD  Schema  is  created,  all  entities  and  relationships  can  be 
defined  at  the  IRD  level  as  shown  in  Table  13. 

Table  13  - IRD  definition 


/*  ird  level  - define  entities  */ 


add  entity  geographic  entity-type  = object; 

add  entity  airside  entity-type  = complex-feature-system; 

add  entity  prosaic-system 

entity-type  = complex-feature-system; 
add  entity  groundside  entity-type  = complex-feature-system; 
add  entity  airfield  entity-type  = feature-system; 
add  entity  runway  entity-type  = feature: 
add  entity  taxiway  entity-type  = feature; 
add  entity  apron  entity-type  = feature; 
add  entity  unpaved-area  entity-type  = feature; 

/*  add  parent-child  relationships  */ 


add  relationship 
add  relationship 
add  relationship 
add  relationship 
add  relationship 
add  relationship 
add  relationship 
add  relationship 


geographic  is-a-parent-of  airside; 
geographic  is-a-parent-of  prosaic-system; 
geographic  is-a-parent-of  groundside-system; 
airside  is-a-parent-of  airfield; 
airfield  is-a-parent-of  runway; 
airfield  is-a-parent-of  taxiway; 
airfield  is-a-parent-of  apron; 
airfield  is-a-parent-of  unpaved-area; 


/*  add  relationships  for  features  */ 


add  relationship  runway  feature-con nected-to- feature  taxiway; 

add  relationship  taxiway  feature-joins-feature  apron; 
add  relationship  apron  feature-apron-adjacent-to-feature 
unpaved-area; 
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11.2  Compiling  the  ANSI-IRDS  Commands 

The  ANSI-IRDS  prototype  program  (AIRDSPP)  developed  at  NIST  translates  ANSI-IRDS 
commands  into  Structured  Query  Language  (SQL)  commands  and  sends  these  to  the  Oracle 
DBMS,  where  the  database  representing  the  IRD  is  maintained  (Oracle  Corporation, 
1989a).  AIRDSPP  performs  various  consistency  checks,  some  of  which  include  calls  to  the 
DBMS  to  access  data.  Formatting  of  the  output  and  some  of  the  entity  selection  is  done 
at  the  AIRDSPP  level.  The  remainder  of  the  selection  is  done  through  the  DBMS  facility 
(Goldfine  and  Kirkendall,  1988). 

When  the  ANSI-IRDS  prototype  is  executed,  the  AIRDSPP  looks  for  the  Oracle  table 
DICTIONARY_NAMES  to  get  a list  of  available  IRDs.  If  this  table  exists,  then  the  user 
is  asked  to  name  the  IRD.  If  not,  AIRDSPP  calls  subroutines  SET^DICT  and  MK_D1CT 
to  create  the  necessary  tables.  Preliminary  parsing  of  each  ANSI-IRDS  command  is 
performed  by  the  subroutines  GETCOM,  READCOM,  INDEXCOMM,  DOCOMMAND, 
CK  SYNTAX  and  MATCH  TEM PLATE. 


After  a command  has  been  read  in  and  parsed,  the  list  of  values  from  the  parse  is  passed 
by  the  subroutine  DO_COMMAND  to  the  subroutine  for  that  command.  Each  command 
has  a corresponding  subroutine,  and  each  subroutine  has,  as  its  name,  an  abbreviation  of 
the  name  of  the  command.  The  subroutines  do  the  required  consistency  checking  and 
translate  the  command  into  SQL  commands.  The  SQL  commands  may  then  be  executed 
against  an  Oracle  database  by  using  the  Oracle  Call  Interface  (OCI)  subroutines  supplied 
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with  the  Oracle  DBMS  (Oracle  Corporation,  1989b). 


11.2.1  GIRDS:  IRD  Output  Command 

Information  on  entities,  relationships,  meta-entities  and  meta-relationships,  as  well  as  system 
generated  meta-attributes  and  attributes  may  be  obtained  from  the  IRD  by  use  of  the 
Output  IRD  and  Output  IRD  Schema  commands.  These  commands  may  be  issued 
interactively  or  in  the  batch  file  as  shown  in  Table  14. 

Table  14  - IRD  output  commands 

/*  ird  output  *: 

output  ird-schema  select  object, 
complex-feature-system,  feature-system,  feature, 

complex-feature-system-is-a-parent-of-feature-system, 

feature-svstem-is-a-parent-of-feature, 

feature-is-a-parent-of-feature, 

object-is-a-parent-of-complex-feature-system, 

feature-connected-to- feature,  feature-joins-feature, 

feature-apron-adjacent-to-feature, 

11.3  GIRDS:  Output 

The  output  from  the  ANSI-IRDS  compilation  provides  a listing  of  all  entities  and 
relationships  added  to  the  IRD  along  with  any  error  messages.  In  addition,  the  IRD  output 
command  issued  in  Section  10.2.5  provides  information  on  entities,  relationships,  meta- 
entities, meta-relationships,  meta-attributes  and  meta-attribute-groups  as  depicted  in  Table 
16  and  explained  in  Table  15. 
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OUTPUT 


Table  15  - Explanation  of  GIRDS  output 
EXPLANATION 


added-by 

assigned  access-name  of  the  effective  IRDS  user 

connectable 

identifies  whether  or  not  the  specified 

implementation-lock 

entity-type  meta-entity  can  participate 
in  any  user-defined  relationship-types 

identifies  those  meta-entities  which  are  required  for  an 
implementation. 

origin 

identifies  the  source  of  this  object  type.  Default  is  IXsuffix, 
where  suffix  is  an  installation-defined  suffix. 

maximum  entity 
assigned  descrip- 
tive name  length 

defines  the  maximum  number  of  characters 
allowed  by  the  implementation  for  an 
entity-descriptive-name. 

maximum 
entity  assigned 
access  name  length 

defines  the  maximum  characters  allowed 
by  the  implementation  for  a meta-entity 
assigned-access-name. 

maximum  entity 
assigned  descrip- 
tive name  length 

define  the  maximum  number  of  characters 
allowed  by  the  implementation  for  a 
meta-entity  assigned-descriptive-name. 

number  of  instances 

identifies  how  many  entities  of  the 
corresponding  type  exist  in  the  IRD. 

number  of  times 
modified 

number  of  times  a particular  meta-entity 
or  meta-relationship  has  been  modified. 

system-generated 

identifies  whether  or  not  an  entity-type  has  system-generated 
entity  assigned-access-names. 

system-lock 

identifies  whether  or  not  a given  meta-entity  or  meta- 
relationship can  be  deleted  from  the  IRD  Schema  by  the 
installation. 

system-date 

identifies  the  current  date 
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Table  15  - Explanation  of  GIRDS  output  (cont.) 


OUTPUT 

system-time 

position 


EXPLANATION 

identifies  the  current  time  of  day 

of  an  entity-type  with  respect  to  a relationship-type 
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Tabic  16  - GIRDS  output  data 


META  ENTITY  = COMPLEXFEATURESYSTEM 
META  ENTITY  TYPE=  ENTITY  TYPE 

META- ATTRIBUTES: 

ADDED_BY  = tony 
CONNECTABLE  = YES 
IMPLEMENT  ATIONLOCK  = OFF 
ORIGIN  = IX 

MAXIMUM_ENTITY_ASSIGNED_DESCRIPTIVE_NAME_LENGTH 
MAXIMUM_ENTITY_ASSIGNED_ACCESS_NAME_LENGTH  = 32 
MINIMUM_ENTITY_ASSIGNED_DESCRIPTIVE_NAME_LENGTH 
NUMBER_OF_INSTANCES  = 3 
NUMBER_OF_TIMES_MODIFIED  = 0 
SYSTEM_GENERATED  = NO 
SYSTEMLOCK  = ON 

META-ATTRIBUTE-GROUPS: 

DATE_TIME_ADDED 

SYSTEMDATE  = 19900823 
SYSTEM_TIME  = 151629 

META-RELATIONSHIPS: 

COMPLEX_FEATURE_SYSTEM_IS_A_PARENT_OF_FEATURE_SYSTEM 

RELATIONSHIP_TYPE_CONNECTS_ENTITY_TYPE 

COMPLEX_FEATURE_SYSTEM 

IMPLEMENTAT10N_L0CK  = OFF 
ORIGIN  = IX 
POSITION  = 1 
SYSTEMLOCK  = ON 

OBJECT_IS_A_PARENT_OF_COMPLEX_FEATURE_SYSTEM 

RELATIONSHIP_TYPE_CONNECTS_ENTITY_TYPE 

COMPLEX_FEATURE_SYSTEM 

IMPLEMENT ATIONLOCK  = OFF 
ORIGIN  = IX 
POSITION  = 2 
SYSTEM  LOCK  = ON 


Table  16  - GIRDS  output  data  (cont.) 


Entity  = AIRSIDE 

Entity  Descriptive-Name  = 

Entity  Type  = COMPLEX_FEATURE_S YSTEM 

Attributes 

ADDED_BY  = tony 

NUMBER_OF_TIMES_MODIFIED  = 0 

Attribute  Groups 
DATETIMEADDED 
SYSTEM_DATE  = 19900823 
S YSTEM  _TIME  = 154953 


Relationships 

AIRSIDE 

COMPLEX_FEATURE_SYSTEM_IS_A_PARENT_OF_FEATURE_S  YSTEM 
AIRFIELD 

GEOGRAPHIC  OBJECT_IS_A_PARENT_OF_COMPLEX_FEATURE_S  YSTEM 
AIRSIDE 


Entity  = AIRFIELD 

Entity  Descriptive-Name  = 

Entity  Type  = FEATURE  S YSTEM 

Attributes 

ADDED_BY  = tony 

NUMBER_OF_TIMES_MODIFIED  = 0 


Attribute  Groups 
DATETIMEADDED 
SYSTEM_DATE  = 19900823 
SYSTEM_TIME  = 155901 

Relationships 

AIRSIDE 

COMPLEX_FEATURE_SYSTEM_lS_A_PARENT_OF_FEATURE_S  YSTEM 
AIRFIELD 

AIRFIELD  FEATURE_SYSTEM_IS_A_PARENT_OF_FEATURE  APRON 

AIRFIELD  FEATURE_SYSTEM_lS_A_PARENT_OF_FEATURE  RUNWAY 

AIRFIELD  FEATURE_SYSTEM_IS_A_PARENT_OF_FEATURE  TAXIWAY 

AIRFIELD  FEATURE_SYSTEM_IS_A_PARENT_OF_FEATURE 
UNPAVED_AREA 
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Table  16  - GIRDS  output  data  (cont.) 


Entity  = RUNWAY 

Entity  Descriptive-Name  = 

Entity  Type  = FEATURE 

Attributes 

ADDED_BY  = tony 

NUMBER_OF_TIMES_MODIFIED  = 0 

Attribute  Groups 
DATE_TIME_ADDED 
SYSTEM_DATE  = 19900823 
SYSTEM_TIME  = 172838 

Relationships 

RUNWAY  FEATURE_ASSOCIATED_WITH_FEATURE  LIGHTING_S YSTEMS 

RUNWAY  FEATURE_CONNECTS_TO_FEATURE  TAXI  WAY 
RUNWAY  FEATURE_HAS_FEATURE  APPROACH_PATH 
RUNWAY  FEATURE_IS_A_PARENT_OF_FUND_DIMEN_ENTITY  POLYGON 
RUNWAY  FEATURE_IS_FEATURE  ZONED 

AIRFIELD  FEATURE_SYSTEM_IS_A_PARENT_OF_FEATURE  RUNWAY 
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12.  CONCLUSIONS  AND  RECOMMENDATIONS 


A number  of  conclusions  follow  from  this  modelling  effort.  These  are  summarized  and 
presented  under  the  headings  of  Spatial  E-R  Modelling,  Spatial  Relations,  Resources 
Needed  for  Modelling  and  the  Integration  of  IRDS  and  GIS. 

12.1  Spatial  E-R  Modelling 


12.1.1 

Parent-child  (isa)  relationships,  an  extension  of  the  E-R  model,  provide  a 
means  of  representing  spatial  relationships.  It  should  be  considered  a 
mandatory  construct  for  E-R  modelling  of  geographic  features  and  their 
representations.  The  isa  relationship  also  permits  hierarchical  aggregation. 
A total  of  127  isa  relationships  occurred  in  the  model,  accounting  for 
approximately  34%  of  all  constructs. 

12.1.2 

Cardinalities  describing  relationships  between  geographic  features  are 
predominantly  T.N  and  N:N.  This  indicates  that  a DBMS  is  required  to 
manage  the  many  tables  containing  non-geographic  data  and  their  linkages  to 
geographic  features. 

12.1.3 

Airports  features  are  modelled  as  belonging  to  three  types  of  complex-feature- 
systems;  namely,  airside,  prosaic  and  groundside.  These  complex-feature- 
systems  are  decomposed  through  isa  relationships  into  feature-systems  and 
then  features.  All  features  are  related  to  their  respective  FDEs  through  isa 
relationships. 

12.1.4 

Of  the  126 geographic  features  modelled.  44%  are  polygons,  29%  are  complex 
lines  and  18%  are  points.  The  remaining  9%  is  almost  equally  divided 
between  nodes  and  lines.  This  is  significant  because  polygons  are 
concatenated  from  boundaries  of  features  which  are  defined  by  complex  lines; 
consequently,  additional  hardware  and  software  is  required  at  airports  to 
process  the  large  number  of  geographic  features  represented  as  polygons. 
These  results  also  indicate  that  a methodical  and  extensive  database  design 
is  required  for  maintaining  an  airport  geographic  database.  This  is  due  to 
the  complexity  of  polygon  features  which  makes  maintenance  of  an  airport 
geographic  database  a difficult  task. 
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12.2  Spatial  Relations 

12.2.1  Twelve  spatial  relationships  (operators)  are  derived  in  the  modelling  process 
(see  Table  9,  Section  10.6).  These  spatial  relationships  confirm  that 
geoprocessing  is  a necessary  requirement  at  airports.  For  example,  the 
relationships  is-in  and  intersect  suggest  that  point-in-polygon  and  polygon 
overlay  processing  requirements  are  necessary. 

12.2.2  Of  the  twelve  spatial  relationships  identified  in  the  GDM,  two  are  considered 
symmetric.  These  are  - outside  and  enclosed  by  - and  are  listed  in  Table  9, 
Section  10.6.  Both  spatial  and  symmetric  relationships  correspond  closely  to 
those  identified  by  the  Association  for  Geographic  Information,  SQL  Working 
Party  (The  Association  for  Geographic  Information,  1990).  These  operators, 
if  standardized,  would  enable  GIS  applications  to  be  ported  more  easily  and 
allow  vendors  to  optimize  the  implementation  of  these  operators. 

12.3  Resources  Needed  for  Modelling 

12.3.1  The  GIRDS  modelling  task  requires  approximately  200  man-hours  of  effort. 
This  is  significant  as  only  a small  subset  of  an  airport  geographic  database  is 
modelled.  It  is  also  significant  that  the  GIS  community  realise  the  effort 
required  to  produce  this  model  and  understand  its  necessity.  If  beneficial 
results  are  to  be  achieved  in  the  management  and  maintenance  of  airport 
geographic  databases,  airport  managers  should  also  realize  that  meaningful 
commitments  and  support  should  be  given  to  staff  and  consultants  contracted 
to  undertake  these  tasks. 

12.3.2  The  GIRDS  modelling  effort  also  requires  significant  computing  resources. 
The  conversion  from  the  GDM  to  the  GIRDS  takes  50  hours  to  write  1350 
lines  of  code.  Compilation  of  this  code  is  done  on  a Digital  Equipment 
Corporation  VAX  11/785  with  16  MB  of  random  access  memory  (RAM)  and 
then  on  a personal  computer  (PC),  386  model  with  2 MB  of  RAM  and  a clock 
speed  of  20  megahertz  (MHZ).  Compilation  times  are  12  hours  and  23  hours 
respectively. 


95 


12.4  Integration  of  IRDS  and  GIS 


12.4.1  Output  from  the  GIRDS  demonstrates  that  airport  entities,  relationships  and 
their  attributes  can  be  maintained  and  monitored  with  the  GIRDS.  This  is 
beneficial  to  TDC  managers  where  equipment  is  being  added  or  upgraded  on 
the  airport;  consequently,  there  is  a requirement  that  new  facilities  be 
referenced  by  name  to  those  being  replaced  or  currently  being  maintained. 

12.4.2  GIRDS  demonstrates  that  it  can  be  used  for  geographic  data  maintenance  as 
all  entities  are  time-stamped  by  the  system  and  the  number  of  times  modified 
is  recorded.  This  implies  that  non-geographic  data  may  be  time-stamped 
because  of  the  established  linkages  to  the  geographic  entities  which  are 
monitored  by  the  ANSI-IRDS.  However,  time-stamping  of  geographic  entities 
occurs  only  when  these  entities  are  changed. 

12.4.3  No  extensions  are  required  to  the  ANSI-IRDS  for  it  to  be  applied  to  the 
management  of  geographic  data.  Commands  provided  by  the  standard 
implementation  of  the  ANSI-IRDS  are  adequate  to  define  geographic  entities 
and  their  relationships  in  the  IRD  Schema  and  the  IRD. 


12.5  Recommendations 

12.5.1  Cardinalities  identified  in  the  modelling  effort  are  not  included  in  the 
conversion  as  they  do  not  have  a direct  influence  on  the  GIRDS.  However, 
as  cardinalities  define  the  number  of  tables  to  be  opened  by  a DBMS  for 
each  entity,  they  should  be  recorded.  It  is  therefore  recommended  that  the 
ANSI-IRDS  Schema  be  extended  to  include  cardinalities  as  attributes  of 
relationships. 

12.5.2  The  GIRDS  conversion  did  not  include  the  controlling  of  meta-data  on  the 
entities  and  further  work  is  required  in  dealing  with  this  issue.  For  example, 
feature  attributes  on  the  entity  runway  may  be  thought  of  as  entities  in  the 
ANSI-IRDS  having  attributes.  This  is  easily  demonstrated  by  considering  the 
relationship  runwav-has-length  and  attaching  attributes  to  the  entity  length  of 
metres  and  centimetres. 
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12.5.3  The  IRDS  Standard  has  demonstrated  the  ability  to  manage  geographic 

information  resources.  The  Canadian  General  Standards  Board  Committee 
on  Geomatics,  has  Working  Group  4 assigned  to  the  development  ot  a 
Cataloguing/Data  Dictionary  Standard.  Based  on  the  results  of  this  report, 
Working  Group  4 should  consider  IRDS  as  a candidate  for  a standard  in 
support  of  the  sharing  of  geomatic  data. 
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ACRONYMS 


Acronym 

Definition 

AASR 

Area  and  Surveillance  Radar 

AGIS 

Airport  Geographic  Information  System 

AIRDSPP 

American  National  Standard  Institute  Information  Resource 
Dictionary  System  Prototype  Program 

ANSI 

American  National  Standards  Institute 

ASCII 

American  Standard  Code  for  Information  Interchange 

ASIS 

Approach  Slope  Indicator  System 

ATB 

Air  Terminal  Building 

CAD 

Computer  Aided  Drafting 

DBMS 

Database  Management  System 

D/D 

Directory/Dictionary 

DRM 

Data  Resource  Management 

DV 

Database  Validation 

E-E-R 

Extended-Entity-Relationship 

E-R 

Entity-Relationship 

E-R-A 

Entity-Relationship-Attribute 

FAP 

Facility  Alteration  Permit 

FD 

Fundamental  Dimensional 

FDE 

Fundamental  Dimensional  Entity 

FIPS 

Federal  Information  Processing  Standard 
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ACRONYMS  (cont.) 


Acronym 

Definition 

GDM 

Geographic  Data  Model 

GIR 

Geographic  Information  Resource 

GIRDS 

Geographic  Information  Resource  Dictionary  System 

GIS 

Geographic  Information  System 

GP 

Geometric  Primitive 

G/P 

Glide  Path 

HCM 

Hardware  Configuration  Management 

HVAC 

Heating,  Ventilation  and  Air  Conditioning 

ICAO 

International  Civil  Aviation  Organization 

IKAP 

Transport  Canada  Internal  Designator 

ILIM 

Institute  for  Land  Information  Management 

ILS 

Instrument  Landing  Systems 

IRD 

Information  Resource  Dictionary 

IRDS 

Information  Resource  Dictionary  System 

IRM 

Information  Resource  Management 

ISA 

Generalization  hierarchy  occurring  when  an  entity  is  partitioned 
by  different  values  of  the  same  entity 

LBPIA 

Lester  B.  Pearson  International  Airport 

LRI 

Land-Related  Information 

MB 

Megabytes 
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ACRONYMS  (cont.) 


Acronym 

Definition 

MHZ 

Megahertz 

NIP 

National  Implementation  Plan 

NIST 

National  Institute  of  Standards  and  Technology 

NTS 

National  Topographic  Series 

OCI 

Oracle  Call  Interface 

PAPIS 

Precision  Approach  Path  Indicator  System 

PC 

Personal  Computer 

PCM 

Profit  Centre  Manager 

PWC 

Public  Works  Canada 

RAM 

Random  Access  Memory' 

SCM 

Software  Configuration  Management 

SRCM 

System  Resource  Configuration  Management 

SDTS 

Spatial  Data  Transfer  Standard 

SQL 

Structured  Query'  Language 

SSR 

Secondary  Surveillance  Radar 

TDC 

Technical  Data  Centre 

TRC 

Technical  Review  Committee 

VASIS 

Visual  Approach  Slope  Indicator  System 
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